¿Por qué un comando remoto SSH obtiene menos variables de entorno que cuando se ejecuta manualmente? [cerrado]

Tengo un comando que funciona bien si ssh a una máquina y lo ejecuto, pero falla cuando intento ejecutarlo usando un comando ssh remoto como:

ssh user@IP <command>

La comparación de la salida de "env" usando ambos métodos resulta en diferentes entornos. Cuando inicio sesión manualmente en la máquina y ejecuto env, obtengo muchas más variables de entorno que cuando ejecuto:

ssh user@IP "env"

¿Alguna idea de por qué?

Hay diferentes tipos de conchas. El shell de ejecución del comando SSH es un shell no interactivo, mientras que su shell normal es un shell de inicio de sesión o un shell interactivo. La descripción sigue, de man bash:

       Un shell de inicio de sesión es aquel cuyo primer carácter de argumento
       cero es un -, o uno comenzó con la opción --login.

       Un shell interactivo es uno iniciado sin opción
       argumentos y sin la opción -c cuya entrada estándar
       y el error están conectados a los terminales (según lo determinado
       por isatty (3)), o uno comenzó con la opción -i. PS1 es
       set y $ - incluye i si bash es interactivo, permitiendo un
       script de shell o un archivo de inicio para probar este estado.

       Los siguientes párrafos describen cómo bash ejecuta su
       archivos de inicio Si alguno de los archivos existe pero no puede ser
       leer, bash informa un error. Tildes se expanden en el archivo
       nombres como se describe a continuación en Tilde Expansion en el
       Sección de expansión.

       Cuando se invoca bash como un shell de inicio de sesión interactivo, o como
       un shell no interactivo con la opción --login, primero
       lee y ejecuta comandos del archivo / etc / profile, si
       ese archivo existe. Después de leer ese archivo, busca
       ~ / .bash_profile, ~ / .bash_login y ~ / .profile, en ese
       orden, y lee y ejecuta comandos del primero
       eso existe y es legible. La opción --noprofile puede
       ser utilizado cuando se inicia el shell para inhibir este comportamiento
       ior.

       Cuando sale un shell de inicio de sesión, bash lee y ejecuta comandos
       del archivo ~ / .bash_logout, si existe.

       Cuando un shell interactivo que no es un shell de inicio de sesión es
       iniciado, bash lee y ejecuta comandos desde ~ / .bashrc,
       si ese archivo existe Esto puede inhibirse mediante el uso de
       - opción opcional. La opción de archivo --rcfile forzará bash
       leer y ejecutar comandos desde un archivo en lugar de
       ~ / .bashrc.

       Cuando bash se inicia de forma no interactiva, para ejecutar un shell
       script, por ejemplo, busca la variable BASH_ENV en
       el medio ambiente, expande su valor si aparece allí,
       y usa el valor expandido como el nombre de un archivo para leer
       y ejecutar Bash se comporta como si el siguiente comando
       fueron ejecutados:
              si [-n "$ BASH_ENV"]; luego . "$ BASH_ENV"; fi
       pero el valor de la variable PATH no se usa para buscar
       para el nombre del archivo.

¿Qué hay de obtener el perfil antes de ejecutar el comando?

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

Puede que le resulte mejor para cambiar eso a ~/.bash_profile, ~/.bashrco lo que sea.

(Como aquí (linuxquestions.org) )

El entorno de Shell no se carga cuando se ejecuta el comando ssh remoto. Puede editar el archivo de entorno ssh:

vi ~/.ssh/environment

Su formato es:

VAR1=VALUE1
VAR2=VALUE2

Además, verifique la sshdconfiguración para la PermitUserEnvironment=yesopción.

Tuve un problema similar, pero al final descubrí que ~ / .bashrc era todo lo que necesitaba.

Sin embargo, en Ubuntu, tuve que comentar la línea que deja de procesar ~ / .bashrc:

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

Encontré que una solución fácil para este problema era agregar la fuente / etc / profile a la parte superior del archivo script.sh que estaba tratando de ejecutar en el sistema de destino. En los sistemas aquí, esto provocó que las variables de entorno que script.sh necesitaba configurar como si se ejecutaran desde un shell de inicio de sesión.

En una de las respuestas anteriores se sugirió que se utilizara ~ / .bashr_profile, etc. No pasé mucho tiempo en esto, pero el problema con esto es que si envía un mensaje a un usuario diferente en el sistema de destino que el shell en el sistema fuente desde el que inicia sesión, me pareció que esto causa que el usuario del sistema fuente nombre que se utilizará para el ~.

Simplemente exporte las variables de entorno que desee sobre la comprobación de un shell no interactivo en ~ / .bashrc.