Pourquoi le $ PATH d'une commande à distance ssh diffère-t-il de celui d'un shell interactif?

J'ai un utilisateur qui n'a apporté aucune modification au $ PATH dans aucun fichier dot: c'est exactement le paramètre par défaut du système. Depuis un shell de connexion:

$ ssh example.com
user@example.com:~$ cat /tmp/hello.hs
#!/bin/bash

echo "$SHELL"
echo "$PATH"

user@example.com:~$ /tmp/hello.hs
/bin/bash
/usr/local/bin:/usr/bin:/bin

Exactement comme spécifié dans /etc/profile. Je trouve cela plutôt inattendu:

$ ssh example.com '/tmp/hello.sh'
/bin/bash       
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

Comme je l'ai dit, il n'y a pas de modification de $ PATH dans ~/.bashrc, ni dans /etc/bash.bashrc. Non ~/.ssh/environmentnon plus. La ssh(1)déclare que la variable d'environnement PATHest

Définissez le PATH par défaut, comme spécifié lors de la compilation de ssh.

mais ce fil de StackOverflow et cet article de liste de diffusion suggèrent que je devrais être capable d'influencer $ PATH pour une commande donnée simplement en modifiant / etc / profile, l'un des fichiers de démarrage du shell, etc.

Que se passe t-il ici?

De ssh(1)la page de manuel: "Si la commande est spécifiée, elle est exécutée sur l'hôte distant au lieu d'un shell de connexion."

Donc, en bref, lorsque vous vous connectez réellement à la machine bash est démarré en tant que shell de connexion et charge les fichiers appropriés, lorsque vous vous connectez à distance et émettez une commande, elle est exécutée à la place de bash, ce qui signifie que ces fichiers ne se chargent PAS. Vous pouvez contourner ce problème avec using su -l -cou similaire dans la partie commande de ssh.

Dans certains cas, j'ai également vu des -targuments pour que ssh fonctionne (allocate tty).

Edit 1 :
Je pense que les informations PATH que vous avez trouvées, que le chemin par défaut (sauf si nous le remplaçons) est celui compilé dans sshd. Je me suis assuré que mon / etc / profile, / etc / bash *, les fichiers dot locaux, etc. ne contenaient aucune information PATH, puis je me suis connecté et j'avais toujours un PATH. J'ai cherché celui-ci dans sshd et je l'ai trouvé là-bas. Donc, comment la page de manuel dit:

ahnberg@remote$ strings /usr/sbin/sshd | grep -i x11 | grep bin
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

Ensuite, j'ajoute PATH=$PATH:/my/testtout en haut de mon .bashrcfichier sur la télécommande et je vérifie à nouveau:

ahnberg@local$ ssh ahnberg@remote "env | grep PATH"
PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/my/test

Je peux donc absolument l'influencer, et PATH par défaut est celui compilé dans sshd. :)

J'ai pu obtenir ssh pour exécuter des commandes en utilisant le chemin d'accès distant en exécutant:

ssh dist@d6 "bash --login -c 'env'"

Ici, env peut être remplacé par la commande que vous souhaitez.

J'ai des clés autorisées, je n'ai donc pas eu besoin d'un mot de passe pour exécuter la commande ou ssh.

J'ai trouvé une solution différente pour résoudre le problème. Ma préférence personnelle est de créer de nouveaux fichiers de configuration au lieu de modifier ceux existants. De cette façon, je peux plus facilement supprimer les modifications de la configuration par défaut.

Voici le contenu de /etc/profile.d/ssh_login.sh:

#!/bin/sh
if [ "$SSH_CONNECTION" ]; then
    echo "User '$USER' logged in from '${SSH_CONNECTION%% *}'"
    . /etc/environment
fi

En utilisant dropbearà la place de openssh-server(cela devrait également fonctionner avec openssh), la variable SSH_CONNECTION est définie automatiquement lorsque je me connecte à distance. J'ai créé une nouvelle configuration de profil de shell pour détecter les connexions SSH, afficher certaines informations à l'écran et, surtout, charger les paramètres d'environnement global à partir de /etc/environmentpour remplacer les valeurs compilées. Veuillez noter que cela n'affecte que les shells SSH interactifs, pas l'exécution des commandes à distance.

Alternativement , si vous utilisez openssh et que vous souhaitez toujours charger l'environnement global, qu'il s'agisse d'un shell interactif, vous pouvez placer un lien symbolique ~/.ssh/comme ceci:

ln -s /etc/environment ~/.ssh/environment

Ensuite, vous devez activer l' PermitUserEnvironmentoption dans /etc/sshd/sshd_config. Ne faites cela que pour les utilisateurs de confiance, car cela pourrait leur permettre de contourner les restrictions d'accès dans certaines configurations à l'aide de mécanismes tels que LD_PRELOAD. Veuillez consulter man sshd_configpour plus d'informations, en particulier comment utiliser des Matchblocs pour contraindre les options à des utilisateurs / groupes spécifiques.

Si vous souhaitez charger le chemin du profil, essayez:

#!/bin/bash -i

en haut du script. De cette façon, le shell est en mode interactif lors de l'exécution du script.

Lorsque bash est invoqué en tant que shell de connexion interactif, ou en tant que shell non interactif avec l'option --login, il lit et exécute d'abord les commandes du fichier / etc / profile, si ce fichier existe. Après avoir lu ce fichier, il recherche ~ / .bash_profile, ~ / .bash_login et ~ / .profile, dans cet ordre, et lit et exécute les commandes à partir du premier qui existe et est lisible. L'option --noprofile peut être utilisée lorsque le shell est démarré pour inhiber ce comportement.

http://linux.die.net/man/1/bash