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

Question

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

ssh user@IP <command>

Comparando la salida de " env " Usando ambos métodos los resultados 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é?

Answer 1

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:

       A  login  shell  is  one whose first character of argument
       zero is a -, or one started with the --login option.

       An interactive shell is  one  started  without  non-option
       arguments  and  without the -c option whose standard input
       and error are both connected to terminals  (as  determined
       by  isatty(3)), or one started with the -i option.  PS1 is
       set and $- includes i if bash is interactive,  allowing  a
       shell script or a startup file to test this state.

       The  following  paragraphs  describe how bash executes its
       startup files.  If any of the files exist  but  cannot  be
       read,  bash reports an error.  Tildes are expanded in file
       names as described below  under  Tilde  Expansion  in  the
       EXPANSION section.

       When  bash is invoked as an interactive login shell, or as
       a non-interactive shell with the --login option, it  first
       reads and executes commands from the file /etc/profile, if
       that file exists.  After reading that file, it  looks  for
       ~/.bash_profile,  ~/.bash_login,  and  ~/.profile, in that
       order, and reads and executes commands from the first  one
       that  exists  and is readable.  The --noprofile option may
       be used when the shell is started to inhibit  this  behav­
       ior.

       When a login shell exits, bash reads and executes commands
       from the file ~/.bash_logout, if it exists.

       When an interactive shell that is not  a  login  shell  is
       started,  bash reads and executes commands from ~/.bashrc,
       if that file exists.  This may be inhibited by  using  the
       --norc  option.   The --rcfile file option will force bash
       to  read  and  execute  commands  from  file  instead   of
       ~/.bashrc.

       When  bash  is  started  non-interactively, to run a shell
       script, for example, it looks for the variable BASH_ENV in
       the  environment,  expands  its value if it appears there,
       and uses the expanded value as the name of a file to  read
       and  execute.   Bash  behaves  as if the following command
       were executed:
              if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
       but the value of the PATH variable is not used  to  search
       for the file name.

Answer 2

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

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

Puede que sea mejor cambiarlo a ~ / .bash_profile , ~ / .bashrc , o lo que sea.

(Como aquí (linuxquestions.org) )

Answer 3

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

También, verifique la configuración de sshd para la opción PermitUserEnvironment = yes.

Answer 4

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 detiene el procesamiento de ~ / .bashrc:

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

Answer 5

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

En una de las respuestas anteriores se sugirió que se usara ~ / .bashr_profile, etc. No dediqué mucho tiempo a esto, pero el problema con esto es que si ssh con un usuario diferente en el sistema de destino que el shell en el sistema de origen desde el que inició sesión, me pareció que esto causa al usuario del sistema de origen. nombre que se utilizará para el ~.

Answer 6

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