~/.profile
est uniquement exécuté par des shells de connexion. Le programme qui appelle le shell décide si le shell sera un shell de connexion (en mettant a -
comme premier caractère de l'argument zéro sur l'invocation du shell). Il n'est généralement pas exécuté lorsque vous vous connectez pour exécuter une commande spécifique.
OpenSSH en particulier invoque un shell de connexion uniquement si vous ne spécifiez pas de commande. Donc, si vous spécifiez une commande, ~/.profile
elle ne sera pas lue.
OpenSSH permet de définir des variables d'environnement côté serveur. Cela doit être activé dans la configuration du serveur , avec la PermitUserEnvironment
directive. Les variables peuvent être définies dans le fichier ~/.ssh/environment
. En supposant que vous utilisez l'authentification par clé publique, vous pouvez également définir des variables par clé dans ~/.ssh/authorized_keys
: ajouter environment="FOO=bar"
au début de la ligne appropriée.
Ssh prend également en charge l'envoi de variables d'environnement. Dans OpenSSH, utilisez la SendEnv
directive dans ~/.ssh/config
. Cependant, la variable d'environnement spécifique doit être activée avec une AcceptEnv
directive dans la configuration du serveur, donc cela risque de ne pas fonctionner pour vous.
Une chose qui, selon moi, fonctionne toujours (curieusement) tant que vous utilisez l'authentification par clé publique consiste à (ab) utiliser l' command=
option dans le authorized_keys
fichier . Une clé avec une command
option n'est valable que pour exécuter la commande spécifiée; mais la commande du authorized_keys
fichier s'exécute avec la variable d'environnement SSH_ORIGINAL_COMMAND
définie sur la commande spécifiée par l'utilisateur. Cette variable est vide si l'utilisateur n'a pas spécifié de commande et attend donc un shell interactif. Vous pouvez donc utiliser quelque chose comme ça dans ~/.ssh/authorized_keys
(bien sûr, cela ne s'appliquera pas si vous n'utilisez pas cette clé pour vous authentifier):
command=". ~/.profile; if [ -n \"$SSH_ORIGINAL_COMMAND\" ]; then eval \"$SSH_ORIGINAL_COMMAND\"; else exec \"$SHELL\"; fi" ssh-rsa …
Une autre possibilité est d'écrire un script wrapper sur le serveur. Quelque chose comme ce qui suit dans ~/bin/ssh-wrapper
:
#!/bin/sh
. ~/.profile
exec "${0##*/}" "$@"
Ensuite , faire des liens symboliques à ce script appelé rsync
, unison
etc. Passe --rsync-path='bin/rsync'
sur la rsync
ligne de commande, et ainsi de suite pour d' autres programmes. Alternativement, certaines commandes vous permettent de spécifier un extrait de shell entier à exécuter à distance, ce qui vous permet de rendre la commande autonome: par exemple, avec rsync, vous pouvez utiliser --rsync-path='. ~/.profile; rsync'
.
Il existe une autre avenue qui dépend de votre shell de connexion étant bash ou zsh. Bash lit toujours ~/.bashrc
quand il est invoqué par rshd ou sshd, même s'il n'est pas interactif (mais pas s'il est appelé comme sh
). Zsh lit toujours ~/.zshenv
.
## ~/.bashrc
if [[ $- != *i* ]]; then
# Either .bashrc was sourced explicitly, or this is an rsh/ssh session.
. ~/.profile
fi
## ~/.zshenv
if [[ $(ps -p $PPID -o comm=) = [rs]shd && $- != *l* ]]; then
# Not a login shell, but this is an rsh/ssh session
. ~/.profile
fi