¿Por qué el reenvío de agente ssh no funciona?

58

En mi propia computadora, ejecutando MacOSX, tengo esto en ~ / .ssh / config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 es una máquina virtual que ejecuta Ubuntu 12.04. Lo digo así:

ssh pupeno@b1

y me conecto sin que me pidan una contraseña porque ya copié mi clave pública. Debido al reenvío, debería poder enviar ssh a pupeno @ b1 desde b1 y debería funcionar, sin pedirme una contraseña, pero no funciona. Me pide una contraseña.

¿Qué me estoy perdiendo?

Este es el resultado detallado del segundo ssh:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

— pupeno
fuente

94

Resulta que mi clave no estaba en el agente, y esto lo solucionó:

OS X :

ssh-add -K

Linux / Unix :

ssh-add -k

Puede enumerar las claves cargadas usando:

ssh-add -l

ssh-add -L # for more detail

— pupeno
fuente

55

Tenga en cuenta que ssh-add -Kes específico para OS X.

— Roger Lipscombe

¿Tienes que hacer esto en cada reinicio?

— Krauser

8

Comprueba si tus ./ssh/id_rsa .ssh/id_dsa .ssh/id_ecdsaarchivos tienen los permisos correctos, que deberían ser propiedad de tu usuario y que deberían ser 600.
Verifique que tenga la clave pública correcta pupeno/.ssh/authorized_keysen b1, y verifique si authorized_keystiene un salto de línea al final de la clave.
Compruebe si tiene ssh-agent ejecutándose, intente cargar claves mediante ssh-add
Pruebe la autenticación y el reenvío basados en GSSAPI con ssh -K

— Daniel Prata Almeida
fuente

El permiso de las claves está bien y la clave en certified_keys está bien (de lo contrario, creo que tendría problemas para conectarme en primer lugar).

— pupeno

¿Tuviste ssh-agent ejecutándose? ¿Qué sucede cuando haces un ssh-add y luego ssh -A pupeno @ b1 y luego ssh pupeno @ b1?

— Daniel Prata Almeida

¿Por qué no actualiza la respuesta para mencionar ssh-add -K y aceptaré la suya en lugar de la mía (ya que la información se publicó casi simultáneamente).

— pupeno

6

Tuve un problema con el servidor sshd que rechazó la solicitud de reenvío del agente debido a que no queda espacio en / tmp. Esto se debió a que sshd necesita crear un socket en / tmp. Limpiar el disco resolvió mi problema.

ssh -v dijo en ese entonces:

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

— BartBiczBoży
fuente

1

Tuve el mismo problema, solo los permisos eran incorrectos en / tmp. ¡¡GRACIAS!!

— nevyn

6

Otra posible razón es el uso compartido de la conexión: es posible que uno ya haya iniciado sesión en el otro host sin el reenvío del agente y el uso compartido de la conexión habilitado. El segundo inicio de sesión con ssh -A(o especificado de manera equivalente en el archivo de configuración) a través de la conexión compartida ignorará silenciosamente el -Aindicador. Solo después de cerrar sesión por completo o deshabilitar la conexión compartida para el segundo inicio de sesión, el reenvío del agente funcionará.

— W.Mann
fuente

2

Para el beneficio de otros googlers que también llegaron a esta pregunta:

Los espacios en blanco incorrectos en un archivo ~ / .ssh / config también pueden causar rasguños en la cabeza.

Recientemente ayudé a uno de mis compañeros de trabajo que tenía esto:

# incorrect
host foobar ForwardAgent yes

en lugar de esto:

# correct
host foobar
  ForwardAgent yes

También me he encontrado con casos en los que la falta de sangría de las directivas en la lista de hosts marcó una diferencia en la funcionalidad, aunque no se supone que lo haga.

— Dale Anderson
fuente

0

Agregue las siguientes líneas al archivo .ssh / config

  Host **Server_Address**
     ForwardAgent yes

Agregar clave al agente SSH

 ssh-add -K

Conectarse al servidor remoto

ssh -v **username**@**Server_Address**

Ejecute la prueba de conexión contra GitHub

ssh -T git@github.com

Ejecute la prueba remota ls contra el repositorio de git objetivo

git ls-remote --heads git@github.com:**account**/**repo**.git

— Tahsin Turkoz
fuente