En supposant que l'utilisateur a /bin/bashcomme shell dans /etc/passwd. Exécute ensuite ssh user@host commandla commande à l'aide de Bash. Cependant, ce shell n'est ni de connexion ni interactif, ce qui signifie que ~/.bash_profileni ~/.bashrcn'est sourcé. Dans ce cas, comment définir la PATHvariable d'environnement pour que les exécutables puissent être trouvés et exécutés? Est-il recommandé de préfixer la commande réelle avec source ~/.bashrc?

Vous avez peu de possibilités:

• Définissez le PATHsur le serveur dans ~/.ssh/environment(doit être activé par PermitUserEnvironment yesdans sshd_config).
• Utiliser le chemin complet vers le binaire
• Comme vous l'avez mentionné, sourcez manuellement .bashrc: préfixez la commande avec . ~/.bashrc(ou source)

Cela dépend à peu près du cas d'utilisation, dans quelle direction vous irez.

Vous associez les paramètres locaux aux paramètres distants .

Localement, une instance bash, le shell en cours d'exécution dans lequel vous écrivez:

ssh user@host command

Exécute la commande ssh (rien de plus) en tant que client ssh.
Pour ce faire, le shell local n'a pas besoin de démarrer un sous-shell ou un nouveau shell ou une connexion.

La commande est exécutée comme une lscommande est: localement.

C'est la commande client ssh qui ouvre une connexion réseau à un système distant , où, si elle est correctement authentifiée, un nouveau shell sera démarré pour exécuter la commande écrite comme argument dans ssh, ou, si aucun argument n'est donné, attendez d'autres commandes sur cette connexion.

Ce nouveau shell distant sera nécessairement un shell de connexion car l'utilisateur distant (sur ce système) doit être authentifié pour se connecter. Ou, si une commande spécifique est donnée, exécutez-la simplement avec les privilèges utilisateur authentifiés.

Vous pouvez voir quels fichiers proviennent en ajoutant un $file sourcedau début de chaque fichier (dans le système distant ) (la racine est nécessaire pour modifier les /etc/fichiers):

$ a=(~/.bashrc ~/.profile /etc/bash.bashrc /etc/profile)
$ for f in "${a[@]}"; do sed -i '1 i\echo "'"$f"' was read"\n' "$f"; done

Et puis il suffit de démarrer une console ssh:

$ ssh sorontar@localhost
/etc/profile was read
/etc/bash.bashrc was read
/home/sorontar/.profile was read
/home/sorontar/.bashrc was read

Dans ce cas, les deux bashrcfichiers ont été lus parce que chaque profilefichier contenait des commandes pour les inclure, et non parce que le shell de connexion les avait directement obtenus.

$ ssh sorontar@localhost :
/etc/bash.bashrc was read
/home/sorontar/.bashrc was read

Dans ce système, où bashrcest lu dans les deux cas.

Pas besoin d'ajouter un source ~/.bashrcà la commande pour l'exécuter.

Changer le CHEMIN

Tout ce que vous devez faire est d'inclure les paramètres corrects pour modifier le "$ PATH", soit dans /etc/bash.bashrc pour tous les utilisateurs qui démarrent un shell dans ce système. Ou ~/.bashrcpour chaque utilisateur qui en a besoin. Vous pouvez ajouter (ou modifier) un squelette d'un utilisateur .bashrcà /etc/skel/avoir tout nouvel utilisateur créé avoir le bon fichier disponible.

Ce qui précède n'est valable que pour bash. Si vous avez besoin que le paramètre fonctionne pour tous les shells, définissez probablement la variable d'environnement PATH en utilisant le fichier ssh ~/.ssh/environmentpour chaque utilisateur qui en a besoin. Ou utilisez-le /etc/ssh/sshrcpour un paramètre global dans le système où le serveur ssh est exécuté (veuillez lire la section Fichiers dans man sshdpour plus de détails).