Quelle est la différence entre la connexion en tant qu'utilisateur et la modification des utilisateurs à l'aide de su via root?

Lorsque vous avez un serveur quelconque, vous pouvez y accéder, par exemple, ssh user1@ipet vous pouvez également faire ssh root@ippour aller à votre utilisateur root avec des privilèges su, puis aller à su user1. Dans ma pensée, ces deux façons devraient me conduire au même environnement utilisateur (dans ce cas, "user1"), mais d'après mon expérience réelle, ce n'est pas le cas, car ssh user1@ipil y a des choses installées qui su user1n'y sont pas.

Pourquoi donc?

SSH démarre un shell de connexion. su, par défaut, non.

En particulier, cela signifie que le ~/.profile(ou fichier similaire) pour cet utilisateur n'est pas d'origine. Les modifications apportées ~/.profilene prendront donc pas effet. Il se pourrait également que:

• même si vous démarrez un shell de connexion, différentes modifications ont été apportées à la racine ~/.profile, ce qui pourrait polluer l'environnement de l'utilisateur.
  • /etc/profileet /etc/profile.d/*peut appliquer les paramètres différemment pour différents utilisateurs (pas par défaut, cependant)
• il peut y avoir différents paramètres pour différents utilisateurs dans la configuration SSH.

• La configuration PAM est différente. Par exemple, /etc/pam.d/ssha:

  session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
  

  considérant que /etc/pam.d/su:

  session       required   pam_env.so readenv=1 envfile=/etc/default/locale
  

  Cela signifie que SSH se charge ~/.pam_environment, mais supas. C'est un gros ~/.pam_environmentproblème , car il s'agit de l'emplacement indépendant du shell pour les variables d'environnement, et il est appliqué si vous vous connectez à partir de l'interface graphique, du TTY ou du SSH.

Pour démarrer un shell de connexion, exécutez l'une des options suivantes:

su - <username>
sudo -iu <username>

Exemple:

# su muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
# su - muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /home/muru/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
# sudo -iu muru sh -c 'echo $HOME $PATH'
/home/muru /home/muru/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# sudo -u muru sh -c 'echo $HOME $PATH'
/root /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# ssh muru@localhost 'echo $HOME $PATH'
/home/muru /home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Même avec SSH, si vous exécutez une commande au lieu de démarrer un shell, un shell de connexion ne sera pas exécuté (notez l'absence de ~/bindans le test SSH, qui est présent dans su -et sudo -i). Pour obtenir le vrai résultat, je vais exécuter mon shell en tant que shell de connexion:

# ssh muru@localhost '$SHELL -ilc "echo \$HOME \$PATH"'
/home/muru /home/muru/bin:/home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

C'est aussi pourquoi sudo suet sudo -ssont des moyens merdiques d'obtenir une coque racine. Ces deux voies sont polluées par l'environnement.

En relation:

• Unix et Linux: su vs sudo -s vs sudo -i vs sudo bash

Dans l'ensemble, c'est principalement une différence stratégique.

Si vous êtes connecté en tant que super utilisateur, vous pouvez changer n'importe quoi tout le temps ... c.-à-d. - il n'y a pas de protection contre les erreurs catastrophiques, vous devrez changer temporairement pour un autre utilisateur pour des raisons de sécurité.

Considérant que: si vous êtes connecté avec des privilèges limités, vous évitez certains risques d'erreurs catastrophiques, car vous devez passer intentionnellement à la racine pour un accès temporaire à ce pouvoir, mais maintenant vous avez la position de repli par défaut pour un utilisateur sûr .

La différence est donc vraiment stratégique, pas technique.