Principalmente trabajo en una Mac y ssh/tmux adjunto a una máquina Linux para hacer mi trabajo. Tengo ssh-agent ejecutándose en la máquina Linux. 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 conectarme 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 configurar correctamente. Preferiría no tener que hacer esto. ¿Alguna idea?
Actualizar
Creo que no me estoy explicando 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 establecido, aunque es ambientado en mi entorno local. Si pongo esto en el entorno de tmux con el setenv comando anterior, todo funciona bien. Mi pregunta es, ¿por qué tengo que ejecutar el comando setenv?
Actualización 2
Más información:
Cuando me adjunto 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 separo y vuelvo a conectar, $SSH_AUTH_SOCK vuelve a no estar configurado.
Respuesta aceptada:
Desde que recibí el Bounty, volveré a publicar mi comentario clave para que esté completo y para evitar que los visitantes con el mismo problema sigan el camino equivocado:
Tmux eliminará las variables de entorno
La página de manual de Tmux establece que update-environment eliminará las variables “que no existen en el entorno de origen […] como si se hubiera dado -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 anterior:
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:
[email protected]:~$ 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 a la que se conectó. 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 va y vuelve a conectar su sesión tmux, verá el problema. Tiene el entorno de cuando se lanzó originalmente tmux, que podría haber sido hace semanas. Ese enchufe en particular murió hace mucho tiempo.
Relacionado:¿prueba de shell si la cadena de varias líneas contiene un patrón especificado en la última línea?Solución
Ya que sabemos que el problema tiene que ver con saber dónde está el socket de autenticación SSH activo actualmente, ¡coloqué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 tengas que poner un "comando de entorno de actualización" en tu tmux.conf. De acuerdo con 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, quien explica el mismo problema para la pantalla.