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

31

Principalmente trabajo en un mac y ssh / tmux adjunto a una máquina Linux para hacer mi trabajo. Tengo ssh-agent corriendo en la máquina de 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 vuelvo a adjuntarme a esta sesión, tengo que ejecutar

tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK

para que las nuevas ventanas tmux tengan $SSH_AUTH_SOCK configurado correctamente. Preferiría no tener que hacer esto. ¿Alguna idea?

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, $SSH_AUTH_SOCK es no configurado, a pesar de que está configurado en mi entorno local. Si pongo esto en el entorno de tmux con el comando setenv anterior, todo funciona bien. Mi pregunta es, ¿por qué tengo que ejecutar el comando setenv?

Actualización 2

Más información:

Cuando me conecto a una sesión existente, $SSH_AUTH_SOCK no está configurado 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 me desprendo y vuelvo a adjuntar, $SSH_AUTH_SOCK vuelve a no estar configurado.

    
pregunta Chris W. 13.05.2013 - 19:21

5 respuestas

12

Me di cuenta de esto. Respuesta corta, necesitaba eliminar SSH_AUTH_SOCK de update-environment . Dado que estaba en esa lista, el valor se estaba perdiendo cada vez que me volvía a unir. Gracias a @djf por la pista. El bit saliente de la página del manual tmux (1) en la sección update-environment :

  

Todas las variables que no existen en el entorno de origen se configuran para que se eliminen del entorno de la sesión (como si se hubiera dado -r al comando set-environment).

    
respondido por el Chris W. 20.05.2013 - 18:16
29

Desde que recibí el Bounty, volveré a publicar mi comentario clave para completar el tema, y para evitar que los visitantes tengan el mismo problema en el camino equivocado:

Tmux eliminará las variables de entorno

La página de manual de Tmux 'indica que el entorno de actualización eliminará las variables "que no existen en el entorno de origen [...] como si se hubiera dado -r al comando set-environment".

Al parecer, lo que causó el problema. Consulte la 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 anterior:

Cómo funciona el reenvío SSH

En la máquina remota, observe el 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 para algún archivo en / tmp. Si examinas este archivo, verás que es un socket de dominio Unix y está conectado a la instancia particular de ssh en la que te conectaste. Es importante destacar que esto cambia cada vez que te conectas.

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

Solución

Ya que sabemos que el problema tiene que ver con saber dónde está el zócalo de autenticación SSH actualmente activo, ¡pongámoslo 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. De acuerdo con página de manual , SSH_AUTH_SOCK ya está cubierto de forma predeterminada.

Crédito

Mi respuesta es un extracto de esta publicación de blog por Mark 'xb95' Smith quien explica lo mismo problema para screen .

    
respondido por el djf 18.05.2013 - 01:58
2

En lugar de usar tmux para manejar mi ssh-agent, tengo que 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.

    
respondido por el demure 13.05.2013 - 19:54
0

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

Antes de que tmux / screen se esté ejecutando:

  1. iniciar sesión.
  2. Inicia una instancia de ssh-agent .
  3. Inicie tmux / screen con las variables de entorno para este ssh-agent .

Esto no pudo usar el reenvío de SSH al cliente pero no se solicitó.

    
respondido por el Hauke Laging 18.05.2013 - 02:26
0

Respondí una pregunta similar en StackOverflow enlace . Dado que esta página apareció primero en mis búsquedas de Google, quería publicar una versión resumida de la misma aquí.

Para que cada sesión 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 FOO explícitamente es necesario para que el panel actual seleccione la variable de entorno. Cualquier panel o ventana posterior que cree para esta sesión de tmux heredará FOO, pero no se mostrará en otras sesiones.

    
respondido por el RobotNerd 21.03.2018 - 00:41

Lea otras preguntas en las etiquetas