ssh-agent no se configura (SSH_AUTH_SOCK, SSH_AGENT_PID env vars no configurados)

Configuré una nueva cuenta de usuario para un amigo en Kubuntu 12.04. Cuando lo usa ssh, obtiene este error:

No se pudo abrir una conexión con su agente de autenticación

Estamos ejecutando sshalgunos scripts de bash.

Después de observar la gran variedad de cosas que pueden conducir a ese error, me encontré con esta solución:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Luego puede ejecutar los sshcomandos (y los scripts bash) como se esperaba.

Antes de ejecutar esos dos comandos, las variables env no se establecen en un terminal:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Después de ejecutar los comandos, las variables env se establecen como se esperaba. Sin embargo, no permanecen configurados (por ejemplo, en un shell diferente o después de reiniciar).

Quiero saber cómo configurar su computadora para que no tenga que ejecutar esos dos comandos para configurar las variables env. No necesito ejecutarlos en mi computadora (nunca). Hasta ahora no veo qué es diferente entre nuestras máquinas.

Veo esta información en la página de manual, pero no me dice cómo Ubuntu normalmente configura el agente automáticamente o qué está sucediendo en la máquina de mi amigo para que esto no funcione para él.

Hay dos formas principales de configurar un agente: la primera es que el agente inicia un nuevo subcomando al que se exportan algunas variables de entorno, por ejemplo, ssh-agent xterm &. El segundo es que el agente imprime los comandos de shell necesarios (se puede generar sh (1) o csh (1) sintaxis) que se pueden evaluar en el shell de llamada, por ejemplo, evaluar ssh-agent -sshells de tipo Bourne como sh (1) o ksh (1) y eval ssh-agent -cpara csh (1) y derivados.

Después de instalar accty reiniciar, esta es la salida de lastcomm:

ssh-agent         F    newuser __         0.12 secs Wed Aug  7 11:02
ssh-agent         F    newuser __         0.00 secs Wed Aug  7 20:34
ssh-agent         F    newuser __         0.02 secs Wed Aug  7 20:02
ssh-agent         F    newuser __         0.01 secs Thu Aug  8 12:39
ssh-agent         F    newuser __         0.02 secs Thu Aug  8 07:45

Desde la página del manual:

F - comando ejecutado después de una bifurcación pero sin un siguiente ejecutivo

No estoy seguro si eso es significativo.

Usted mencionó que su usuario está sshingresando, no iniciando sesión localmente. Por lo que el use-ssh-agentde /etc/X11/Xsession.optionsuna cortina de humo: no se ejecutará en sesiones SSH, si inicia la sesión en un escritorio X11 GUI localmente (o utilizando alguna sesión X11 virtual como sobre VNC o RDP).

En su lugar, debe verificar si libpam-sshestá instalado en cualquiera de los sistemas. Se puede configurar para autenticar a un usuario utilizando frases de contraseña de clave privada SSH, pero eso es opcional y deberá colocar la clave específicamente ~/.ssh/login-keys.d/para esa funcionalidad.

Sin embargo, su otra característica es iniciar automáticamente un agente SSH en cualquier sesión de inicio de sesión y agregar automáticamente claves privadas SSH al agente si su frase de contraseña es la misma que la contraseña de inicio de sesión del usuario. Estoy pensando que esta podría ser la causa del comportamiento diferente entre sus sistemas.

Para el

$ eval `ssh-agent -s`

construir para trabajar cuando se coloca en un "script de inicio", su sesión y, en última instancia, el terminal donde espera el entorno, deben ser descendientes (por forky exec) de ese script. La razón es que la salida de ssh-agent -s, cuando se evalúa, establece variables de entorno en la llamada de shelleval . Formulario allí, pueden ser transmitidos, y también pueden perderse en el camino.

Entonces, si el ssh-agentscript A lo ejecuta en algún lugar durante el inicio de sesión, pero el terminal B en el que inicia el script de shell no es un descendiente de A, entonces no puede ver el entorno en B.

Si por casualidad ha ssh-agentcomenzado como systemd --userservicio, puede que tenga que usar la convención en su lugar: no permita ssh-agent especificar las variables, pero use el conocimiento común al iniciar el agente y al iniciar la sesión. Por ejemplo, mi ~/.config/systemd/user/ssh-agent.serviceaspecto es el siguiente:

[Unit]
Description=SSH agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Y en mi ~/.profiletengo la linea

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Tenga %ten cuenta que en el primero corresponde a ${XDG_RUNTIME_DIR}en el segundo.

Nota: ¡ No estoy contento con esto!

Encontré la respuesta aquí:

http://www.bernatchez.net/userauth.html

En ubuntu, la utilidad ssh-add no puede cargar los archivos de certificado. Ocurre cuando el agente es el implementado por gnome-keyring. La solución es dejar de usar el componente ssh de gnome-keyring. Dado que el proceso de inicialización realmente inicia un verdadero agente ssh y luego lanza gnome-keyring-ssh.desktop, que activa AUTH_SOCKET para que se haga cargo, podemos volver al agente ssh original deshabilitando gnome-keyring-ssh.desktop.

Deshabilite gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Agregue la siguiente línea al archivo de escritorio y guárdelo, luego reinicie:

X-GNOME-Autostart-enabled=false

Mencionaste eso

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Funciona como se desee. Por lo tanto, solo necesita ejecutarlos en el momento adecuado, en .bash_profile o .xsession. Agregue declaraciones de depuración (date; env|sort) >> /tmp/logpara ayudarlo a comprender exactamente cuándo se ejecutan.