¿Por qué tengo que volver a configurar env vars en tmux cuando vuelvo a conectar?

37

Principalmente trabajo en un mac y ssh / tmux se conecta a una máquina Linux para hacer mi trabajo. Tengo ssh-agent ejecutándose en la máquina Linux. yo tengo

set -g update-environment "SSH_AUTH_SOCK SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY"

en mi .tmux.conf. Sin embargo, cada vez que me vuelvo a conectar a esta sesión, tengo que ejecutar

tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK

para que las nuevas ventanas tmux se hayan $SSH_AUTH_SOCKconfigurado correctamente. Preferiría no tener que hacer esto. ¿Algunas ideas?

Actualizar

Creo que no estoy explicando esto bien. Aquí está mi función de shell para abrir un shell en una máquina remota:

sshh () {
    tmux -u neww -n ${host} "ssh -Xt ${host} $*"
}

Cuando tmux ejecuta este comando ssh, no$SSH_AUTH_SOCK está configurado, aunque esté configurado en mi entorno local. Si pongo esto en el entorno de tmux con el comando anterior, todo funciona bien. Mi pregunta es, ¿por qué tengo que ejecutar el comando setenv?setenv

Actualización 2

Más información:

Cuando me adjunto a una sesión existente, $SSH_AUTH_SOCKno se establece en el entorno tmux (o entorno global).

% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK

Si lo configuro manualmente, las cosas funcionan:

% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK

Si lo separo y lo $SSH_AUTH_SOCKvuelvo a conectar, vuelve a no estar configurado.

Chris W.
fuente
No se trata de SSH en absoluto, ¿verdad? ¿Qué variables de entorno tiene en un nuevo shell, cuál es el resultado env?
Hauke ​​Laging
¿Qué shell estás usando en la Mac? ¿Golpetazo?
slm
@HaukeLaging Realmente se trata de tmux.
Chris W.
@slm Estoy usando zsh.
Chris W.
¿Qué pasa con las ventanas existentes? ¿Todavía funcionan?
Hauke ​​Laging

Respuestas:

35

Desde que recibí el Bounty, volveré a publicar mi comentario clave por razones de integridad y para evitar que los visitantes con el mismo problema se equivoquen:

Tmux eliminará las variables de entorno

La página de manual de Tmux dice que update-environment eliminará las variables "que no existen en el entorno de origen [...] como si se diera -r al comando set-environment".

Aparentemente eso fue lo que causó el problema. Vea la respuesta de Chris a continuación . Sin embargo, todavía no puedo imaginar cómo la variable podría estar ausente en el "entorno de origen" y, sin embargo, ser válida en la ventana tmux recién creada ...


Respuesta previa:

Cómo funciona el reenvío SSH

En la máquina remota, eche un vistazo al entorno de su shell después de establecer la conexión SSH:

user@remote:~$ env | grep SSH
SSH_CLIENT=68.38.123.35 45926 22
SSH_TTY=/dev/pts/0
SSH_CONNECTION=68.38.123.35 48926 10.1.35.23 22
SSH_AUTH_SOCK=/tmp/ssh-hRNwjA1342/agent.1342

El importante aquí es SSH_AUTH_SOCK, que actualmente está configurado en algún archivo en / tmp. Si examina este archivo, verá que es un socket de dominio Unix, y está conectado a la instancia particular de ssh en la que se conectó. Es importante destacar que esto cambia cada vez que se conecta.

Tan pronto como cierre la sesión, ese archivo de socket en particular desaparecerá. Ahora, si va y vuelve a conectar su sesión tmux, verá el problema. Tiene el entorno de cuando tmux se lanzó originalmente, que podría haber sido hace semanas. Ese zócalo en particular hace mucho que está muerto.

Solución

Dado que sabemos que el problema tiene que ver con saber dónde está el socket de autenticación SSH actualmente en vivo, ¡colóquelo en un lugar predecible!

En su archivo .bashrc o .zshrc en la máquina remota, agregue lo siguiente:

# Predictable SSH authentication socket location.
SOCK="/tmp/ssh-agent-$USER-screen"
if test $SSH_AUTH_SOCK && [ $SSH_AUTH_SOCK != $SOCK ]
then
    rm -f /tmp/ssh-agent-$USER-screen
    ln -sf $SSH_AUTH_SOCK $SOCK
    export SSH_AUTH_SOCK=$SOCK
fi

No creo que tenga que poner un 'comando de actualización de entorno' en su tmux.conf. Según la página del manual, SSH_AUTH_SOCK ya está cubierto de forma predeterminada.

Crédito

Mi respuesta es un extracto de esta publicación de blog de Mark 'xb95' Smith que explica el mismo problema para la pantalla .

djf
fuente
Gracias por su atenta respuesta. Mi pregunta no se trata de configurar mi $SSH_AUTH_SOCKen nuevos shells, se trata de configurar $SSH_AUTH_SOCKen nuevas ventanas tmux antes de que se obtenga .bashrc / .zshrc.
Chris W.
@ChrisW. Supuse que el script debería colocarse en el archivo rc de su shell de inicio de sesión en la máquina remota. Si inicia sesión, se genera un nuevo shell, SSH_AUTH_SOCK se cambia y se exporta . Cuando inicie tmux, heredará SSH_AUTH_SOCK del entorno principal. Dado que el valor de SSH_AUTH_SOCK ahora está fijo, tmux debería seguir trabajando en inicios de sesión posteriores ... Tal vez no
entendí
Supongo que mi confusión es sobre el entorno en el que tshux ejecuta ssh en el contexto de una nueva ventana (por ejemplo tmux neww ssh somehost).
Chris W.
Un problema con este enfoque es que una segunda conexión SSH a la máquina sobrescribirá el valor de SSH_AUTH_SOCK. Este enfoque solo funciona mientras la sesión tmux está abierta a través de la conexión SSH más reciente.
phylae
12

Me di cuenta de esto. Respuesta corta, necesitaba eliminar SSH_AUTH_SOCKde update-environment. Como estaba en esa lista, el valor se desvaneció cada vez que lo volví a conectar. Gracias a @djf por la pista. Lo más destacado de la página del comando man tmux (1) en la update-environmentsección:

Cualquier variable que no exista en el entorno de origen está configurada para eliminarse del entorno de sesión (como si se diera -r al comando set-environment).

Chris W.
fuente
1
@ChrisW. ¿Podrías ser un poco más grande y claro? Creo que tengo el mismo problema: a veces el agente deja de funcionar cuando vuelvo a conectar las sesiones de tmux. Tiene algún sentido ya que la conexión SSH es nueva y cuando ssh iniciará un nuevo agente. ¿Qué tengo que cambiar para que funcione? Espero que sea algo que pueda ejecutar, ya que no quiero tener que volver a configurar cada máquina en la que estoy trabajando. - Ahora tengo un contenedor ssh que inicia tmux de forma remota o restaura las conexiones existentes, probablemente podría hacer algo antes de restaurar el tmux.
sorin
@ChrisW. Las respuestas cortas a veces son agradables, pero ¿podría dar una respuesta larga? Estoy luchando para que esto funcione y nada en esta publicación está funcionando para mí.
redbmk
@sorin @redbmk Lo siento por eso. Esta es la única línea que tuve que cambiar en mi .tmux.confpara que esto funcione: set -g update-environment "SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY" ¿Está viendo problemas ssho variables de entorno en general?
Chris W.
2

En lugar de usar tmux para manejar mi agente ssh, tengo bash para manejarlo con:

### SSH Agent ### {{{
SSH_ENV="$HOME/.ssh/environment"

function start_agent {
    echo "Initialising new SSH agent..."
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
    echo succeeded
    chmod 600 "${SSH_ENV}"
    . "${SSH_ENV}" > /dev/null
    /usr/bin/ssh-add;
}

## Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
    . "${SSH_ENV}" > /dev/null
    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
        start_agent;
    }
  else
    start_agent;
fi
### End SSH Agent ### }}}

Tengo esto en mi ~ / bashrc , y funciona muy bien.

recatado
fuente
$SSH_AUTH_SOCKestá configurado correctamente en mis shells, pero cuando hago algo como esto tmux neww ssh somehost, se me pedirá mi frase de contraseña para desbloquear mi clave privada a menos que ejecute tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK.
Chris W.
1

Respondí una pregunta similar en StackOverflow https://stackoverflow.com/a/49395839/241025 . Como esta página apareció primero en mis búsquedas en Google, quería publicar una versión resumida aquí.

Para que cada sesión de tmux tenga un conjunto de variables de entorno personalizadas, debe agregar los valores a las variables de entorno por sesión de tmux. Aquí hay un ejemplo de cómo hacerlo.

tmux new-session -s one
tmux setenv FOO foo-one
export FOO='foo-one'

El último paso para exportar explícitamente FOO es necesario para que el panel actual recoja la variable de entorno. Los paneles o ventanas posteriores que cree para esta sesión de tmux heredarán FOO, pero no se mostrarán en otras sesiones.

RobotNerd
fuente
0

La explicación de djf trae otra posible solución a mi mente:

Antes tmux/ se screenestá ejecutando:

  1. Iniciar sesión.
  2. Comience una instancia de ssh-agent.
  3. Comience tmux/ screencon las variables de entorno para esto ssh-agent.

Esto no pudo usar el reenvío de SSH al cliente, pero eso no fue solicitado.

Hauke ​​Laging
fuente
1
ssh-agentno se une a TTY, ¿por qué debería eliminarse al cerrar sesión (?), ¿por qué usarlo nohup?
Poige
@poige Correcto.
Hauke ​​Laging