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:
~/.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)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:
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.
la source