Pourquoi une commande à distance SSH obtient-elle moins de variables d'environnement que lorsqu'elle est exécutée manuellement? [fermé]

J'ai une commande qui fonctionne correctement si je ssh sur une machine et l'exécute, mais échoue lorsque j'essaie de l'exécuter à l'aide d'une commande ssh distante comme:

ssh user@IP <command>

La comparaison de la sortie de "env" en utilisant les deux méthodes se résume dans différents environnements. Lorsque je me connecte manuellement à la machine et que j'exécute env, j'obtiens beaucoup plus de variables d'environnement que lorsque j'exécute:

ssh user@IP "env"

Une idée pourquoi?

Il existe différents types d'obus. Le shell d'exécution de commande SSH est un shell non interactif, tandis que votre shell normal est soit un shell de connexion, soit un shell interactif. La description suit, de man bash:

       Un shell de connexion est celui dont le premier caractère d'argument
       zéro est un -, ou un a commencé avec l'option --login.

       Un shell interactif est un shell démarré sans option
       et sans l'option -c dont l'entrée standard
       et l'erreur sont tous deux connectés aux bornes (comme déterminé
       par isatty (3)), ou l'un a commencé avec l'option -i. PS1 est
       set et $ - inclut i si bash est interactif, permettant une
       script shell ou un fichier de démarrage pour tester cet état.

       Les paragraphes suivants décrivent comment bash exécute son
       fichiers de démarrage. Si l'un des fichiers existe mais ne peut pas être
       lu, bash signale une erreur. Les tildes sont développés dans le fichier
       noms comme décrit ci-dessous sous Tilde Expansion dans le
       Section EXPANSION.

       Lorsque bash est invoqué en tant que shell de connexion interactif, ou en tant que
       un shell non interactif avec l'option --login, il commence par
       lit et exécute 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 ce
       ordre, et lit et exécute les commandes du premier
       qui existe et qui est lisible. L'option --noprofile peut
       être utilisé lorsque le shell est démarré pour inhiber ce comportement
       ior.

       Lorsqu'un shell de connexion se ferme, bash lit et exécute des commandes
       à partir du fichier ~ / .bash_logout, s'il existe.

       Lorsqu'un shell interactif qui n'est pas un shell de connexion est
       démarré, bash lit et exécute les commandes de ~ / .bashrc,
       si ce fichier existe. Cela peut être inhibé en utilisant le
       --norc option. L'option de fichier --rcfile forcera bash
       pour lire et exécuter des commandes à partir d'un fichier au lieu de
       ~ / .bashrc.

       Lorsque bash est démarré de manière non interactive, pour exécuter un shell
       par exemple, il recherche la variable BASH_ENV dans
       l'environnement, augmente sa valeur s'il y apparaît,
       et utilise la valeur développée comme nom d'un fichier à lire
       et exécuter. Bash se comporte comme si la commande suivante
       ont été exécutés:
              if [-n "$ BASH_ENV"]; puis . "$ BASH_ENV"; Fi
       mais la valeur de la variable PATH n'est pas utilisée pour rechercher
       pour le nom de fichier.

Que diriez-vous de trouver le profil avant d'exécuter la commande?

ssh user@host "source /etc/profile; /path/script.sh"

Vous trouverez peut - être qu'il valait mieux changer cela à ~/.bash_profile, ~/.bashrcou peu importe.

(Comme ici (linuxquestions.org) )

L'environnement Shell ne se charge pas lors de l'exécution de la commande ssh distante. Vous pouvez modifier le fichier d'environnement ssh:

vi ~/.ssh/environment

Son format est:

VAR1=VALUE1
VAR2=VALUE2

Vérifiez également la sshdconfiguration pour l' PermitUserEnvironment=yesoption.

J'ai eu un problème similaire, mais à la fin j'ai découvert que ~ / .bashrc était tout ce dont j'avais besoin.

Cependant, dans Ubuntu, j'ai dû commenter la ligne qui arrête le traitement de ~ / .bashrc:

#If not running interactively, don't do anything
[ -z "$PS1" ] && return

J'ai trouvé une solution facile à ce problème: ajouter le fichier source / etc / profile en haut du fichier script.sh que j'essayais d'exécuter sur le système cible. Sur les systèmes ici, cela a entraîné la configuration des variables d'environnement nécessaires à script.sh comme si elles s'exécutaient à partir d'un shell de connexion.

Dans l'une des réponses précédentes, il a été suggéré d'utiliser ~ / .bashr_profile etc ... Je n'y ai pas passé beaucoup de temps, mais le problème est que si vous utilisez un utilisateur différent sur le système cible que le shell du système source à partir duquel vous vous connectez, il me semble que cela provoque l'utilisateur du système source. nom à utiliser pour le ~.

Exportez simplement les variables d'environnement que vous voulez au-dessus de la recherche d'un shell non interactif dans ~ / .bashrc.