La input de key pública de SSH falla sin patrón

(previamente publicado en stackoverflow por error)

Estoy ejecutando un montón de serveres con Ubuntu 14.04.1 (sol, hyperion, …) todos los que utilizan keys públicas (OpenSSH_6.6.1, OpenSSL 1.0.1f 6 de enero de 2014 en todas las máquinas) para rsync sin problemas. Casi todos…

Una connection falla sin cambios en las configuraciones o keys. Entonces intentaré volver a agregar las llaves, comprobar para ECDSA, reboot / restart ssh y él trabaja otra vez. O no lo hace. En este caso sólo espero una cantidad aleatoria de time (1h hasta 3 meses) y hacer lo mismo. Esta vez se soluciona el problema – por un time.

Las partes relevantes de un ssh -vvv diff:

Conexión exitosa

debug1: Host 'hyperion.internal' is known and matches the ECDSA host key. debug1: Found key in /home/bar/.ssh/known_hosts:20 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/bar/.ssh/id_rsa (0x7f..), debug2: key: /home/bar/.ssh/id_dsa ((nil)), debug2: key: /home/bar/.ssh/id_ecdsa ((nil)), debug2: key: /home/bar/.ssh/id_ed25519 ((nil)), debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: prefernetworking gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining prefernetworking: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/bar/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp 95:... debug3: sign_and_send_pubkey: RSA 95:... debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). Authenticated to hyperion.internal ([172.16.0.10]:22). 

Conexión fallida

 debug1: Host 'hyperion.internal' is known and matches the ECDSA host key. debug1: Found key in /home/bar/.ssh/known_hosts:20 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/bar/.ssh/id_rsa (0x7f..), debug2: key: /home/bar/.ssh/id_dsa ((nil)), debug2: key: /home/bar/.ssh/id_ecdsa ((nil)), debug2: key: /home/bar/.ssh/id_ed25519 ((nil)), debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: prefernetworking gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining prefernetworking: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/bar/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/bar/.ssh/id_dsa debug3: no such identity: /home/bar/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/bar/.ssh/id_ecdsa debug3: no such identity: /home/bar/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/bar/.ssh/id_ed25519 debug3: no such identity: /home/bar/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining prefernetworking: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password 

Cosas que he comprobado varias veces:

  • permissions para .ssh / e id_rsa en todas las máquinas
  • que estoy usando las teclas correctas
  • que ssh-copy-id -i /home/bar/.ssh/id_rsa europa@hyperion.internal copy las keys correctas en el fichero authorized_hosts correcto

Lo que realmente no ayudó sino que se sumó al efecto vodoo / heisenbug:

  • reiniciar las máquinas
  • reiniciar el service ssh
  • jugando con las opciones ssh globales

He pegado los loggings completos con alguna información networkingactada en pastebin: wall of log

El problema ha sido resuelto, no estaba relacionado con ssh en absoluto:

hyperion.internal tenía una casa cifrada, por lo que la búsqueda de key falló cuando no estaba montado en /home/europe .

En retrospectiva bastante obvio, pero explica el efecto heisenbug de no fallar al observar los loggings en la máquina (mientras que está conectado, por supuesto …)

Espero que esto ayude por lo less algún otro.

 debug1: Offering RSA public key: /home/bar/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password 

Esto indica que el server no aceptó su key privada. Desafortunadamente, el server no proporciona al cliente más detalle sobre por qué no aceptó la key, por lo que realmente necesita solucionar esto en el server.

Empezaría por comprobar el syslogs en /var/log en el server para cualquier post de sshd indica por qué rechazó el bash de authentication.

Si tiene acceso root en el server remoto, puede ejecutar una instancia de debugging de sshd y, a continuación, conectarse a ella con un cliente. En el server remoto, se convierte en root y ejecute /path/to/sshd -d -p 2222 . Esto lanzará una instancia de sshd que escucha en el puerto 2222. Aceptará una connection e imprimirá información de debugging en su terminal.

A continuación, en el cliente, ejecute ssh normalmente pero incluya -p 2222 para conectarse al puerto correcto. Si el inicio de session falla, compruebe la salida de debugging impresa por el server.

Para mí, esto era un problema de permissions que implicaba el directory de inicio también. Los permissions para el directory de inicio en el server de destino se estableció en 775. De lo que descubrí, los permissions de directory principal deben establecerse en 755 o less. Esto lo establece en donde ningún usuario que no sea el propietario del directory de inicio se le permite tener permissions de escritura.

Parece un problema de server:

 debug1: Offering RSA public key: /home/bar/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password 

El server no parece estar enviando una respuesta aquí. Intentaría poner en marcha la debugging hasta 11 en el lado del server y ver de qué se queja.

¿Cuánto time transcurre después de enviar el package publickey esperando la respuesta cuando falla? Si yo

Chown los files creados por la raíz (no sólo chmod) de nuevo a esa count de usuario original. También puede probar con Userify, ver si funciona y que tiene key pública sin errores.

A menudo he tenido problemas ssh debido a la misma dirección MAC que se asocia con varios nombres de computadora y viceversa. Hay opciones de command-line para que ssh maneje esto. También puede eliminar o editar el file de hosts conocidos para eliminar el problema. No estoy seguro si esto ayuda, pero esto cubre el 90% de mis problemas ssh.

Intereting Posts