Asumiendo que el usuario tiene /bin/bashcomo shell /etc/passwd. Luego ssh user@host commandejecuta el comando usando Bash. Sin embargo, ese shell no es de inicio de sesión ni interactivo, lo que significa que ~/.bash_profileni ~/.bashrctiene origen. En ese caso, ¿cómo establecer la PATHvariable de entorno para que se puedan encontrar y ejecutar ejecutables? ¿Se recomienda prefijar el comando real con source ~/.bashrc?
Respuestas:
Tienes pocas posibilidades:
PATHen el servidor en ~/.ssh/environment(debe estar habilitado por PermitUserEnvironment yesin sshd_config)..bashrc: prefija el comando con . ~/.bashrc(o source)Depende en gran medida del caso de uso, en qué dirección irá.
~/.bashrcno es necesario, ocurre de manera predeterminada. De hecho, me parece una mala idea.
$PATHno se expande desde ~/.ssh/environment, al menos no hacia adentro OpenSSH_7.9p1, OpenSSL 1.1.1b 26 Feb 2019.
PermitUserEnvironment(predeterminado en versiones recientes)
PATH="$PATH:/new/path"a mi ~/.ssh/environmentcuando debería haber sidoPATH=$PATH:/new/path
Está equiparando la configuración local con la configuración remota .
Localmente, una instancia de bash, el shell actual en el que escribe:
ssh user@host commandEjecutará el comando ssh (nada más) como un cliente ssh.
Para hacerlo, el shell local no necesita iniciar un sub-shell o un nuevo shell o iniciar sesión.
El comando se ejecuta como un lscomando es: localmente.
Es el comando ssh del cliente que abre una conexión de red a un sistema remoto , donde, si se autentica correctamente, se iniciará un nuevo shell para ejecutar el comando escrito como un argumento para ssh o, si no se proporciona ningún argumento, espere más comandos en esa conexión
Ese nuevo Shell remoto necesariamente será un shell de inicio de sesión, ya que el usuario remoto (en ese sistema) debe autenticarse para iniciar sesión. O, si se da algún comando específico, simplemente ejecute dicho comando con los privilegios de usuario autenticado.
Puede ver qué archivos se obtienen agregando un $file sourcedal inicio de cada archivo (en el sistema remoto ) (se necesita root para cambiar los /etc/archivos):
$ a=(~/.bashrc ~/.profile /etc/bash.bashrc /etc/profile)
$ for f in "${a[@]}"; do sed -i '1 i\echo "'"$f"' was read"\n' "$f"; doneY luego simplemente inicie una consola ssh:
$ ssh sorontar@localhost
/etc/profile was read
/etc/bash.bashrc was read
/home/sorontar/.profile was read
/home/sorontar/.bashrc was readEn este caso, ambos bashrcarchivos se leyeron porque cada profilearchivo tenía comandos para incluirlos, no porque el shell de inicio de sesión los obtuviera directamente.
$ ssh sorontar@localhost :
/etc/bash.bashrc was read
/home/sorontar/.bashrc was readEn este sistema, donde bashrcse lee en ambos casos.
No es necesario agregar un source ~/.bashrccomando para ejecutar.
Todo lo que necesita hacer es incluir la configuración correcta para cambiar el "$ PATH", ya sea /etc/bash.bashrcpara todos los usuarios que inician un shell en este sistema. O ~/.bashrcpara cada usuario que lo necesite. Puede agregar (o editar) un esqueleto de un usuario .bashrcpara /etc/skel/que cualquier nuevo usuario creado tenga el archivo correcto disponible.
Lo anterior es válido solo para bash. Si necesita que la configuración funcione para todos los shells, probablemente configure la variable de entorno PATH utilizando el archivo ssh ~/.ssh/environmentpara cada usuario que lo necesite. O use /etc/ssh/sshrcpara una configuración global en el sistema donde se ejecuta el servidor ssh (lea la sección Archivos man sshdpara obtener más detalles).
.bashrces de origen, pero probablemente tiene una prueba de interactividad en la parte superior. Las cosas que colocas antes de esa verificación deberían aplicarse, y eso es lo que hago para forzar la RUTA cuando el servidor no permite el entorno o el uso del usuario~/.pam_environment.