SSH démarre un shell de connexion. su , par défaut pas.
En particulier, cela signifie que ~/.profile (ou un fichier similaire) pour cet utilisateur n'est pas source. Les modifications apportées dans ~/.profile ne prendront donc pas effet. Il se pourrait aussi que:
- Même si vous démarrez un shell de connexion, différentes modifications ont été apportées à
~/.profile de la racine, ce qui peut polluer l'environnement de l'utilisateur.
-
/etc/profile et /etc/profile.d/* peuvent appliquer des paramètres différents pour différents utilisateurs (mais pas par défaut)
- il peut y avoir différents paramètres pour différents utilisateurs dans la configuration SSH.
-
La configuration de PAM est différente. Par exemple, /etc/pam.d/ssh a:
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
alors que /etc/pam.d/su a:
session required pam_env.so readenv=1 envfile=/etc/default/locale
Cela signifie que les charges SSH ~/.pam_environment , mais pas su . Ceci est un grand, puisque ~/.pam_environment est le lieu de shell indépendant pour les variables d'environnement, et il est appliqué si vous vous connectez à partir de l'interface graphique, l'ATS ou SSH.
Pour démarrer un shell de connexion, exécutez l'une des opérations 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 [email protected] '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 lancer un shell, un shell de connexion ne sera pas exécutée (notez l'absence de ~/bin dans le test SSH, qui est présent en su - et sudo -i ). Pour obtenir le vrai résultat, je vais lancer mon shell en tant que shell de connexion:
# ssh [email protected] '$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 la raison pour laquelle sudo su et sudo -s sont des moyens minables d'obtenir un shell racine. Ces deux manières sont polluées par l'environnement.
Connexes: