Error de SSH: tipo de clave desconocida '----- BEGIN'

Tengo problemas para usar claves autorizadas para iniciar sesión en SSH en un servidor remoto. Los mensajes de error que recibo se ven así:

OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xx [xxx.xx.xx.xx] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /Users/bfenker/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
...
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/bfenker/.ssh/id_rsa type 1
ssh_exchange_identification: Connection closed by remote host

Otras preguntas en este sitio han publicado preguntas similares, y la solución generalmente fue verificar dos veces todos los permisos en el lado del cliente, lo que hice:

drwxr-xr-x+ 23 bfenker          staff   782 May  8 11:02 bfenker
drwx------   8 bfenker          staff   272 May  8 10:05 .ssh
-rw-------   1 bfenker  staff  1675 May  8 09:51 id_rsa
-rw-r--r--   1 bfenker  staff   418 May  8 09:51 id_rsa.pub
-rw-------   1 bfenker  staff   999 May  8 09:46 identity
-rw-r--r--   1 bfenker  staff   663 May  8 09:46 identity.pub
-rw-r--r--   1 bfenker  staff   416 May  8 09:06 known_hosts

Puedo usar la clave autorizada para SSH en otro servidor y desde este servidor SSH en el servidor que quiero. Esta es una solución pasable que estoy intentando solucionar, pero creo que también muestra que tanto mi cliente como el servidor están configurados correctamente.

Tenga en cuenta que cuando SSH con éxito en un servidor diferente, recibo los mismos mensajes de error, pero parece recuperarse comenzando con las líneas:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0

¿Alguien sabe por qué esto funciona en algunos casos pero no en el caso que quiero? Cualquier otra sugerencia sería muy apreciada!

Necroquestion! Basado en el hecho de que puede usar esta clave para iniciar sesión en otro servidor @ michael-hampton está en el camino correcto: hay algo (firewall / tcp wrappers / sshd config) en el servidor de destino que niega el acceso. Toda esta charla sobre formatos de clave incorrectos es una pista falsa basada en la interpretación incorrecta de la información de depuración. La línea

debug1: identity file /Users/bfenker/.ssh/id_rsa type 1

indica que ssh pudo entender la clave.

Su clave SSH está almacenada en el formato incorrecto. OpenSSH utiliza claves que se colocan en una sola línea. Necesita ssh-keygencon -iy -mopciones, ver man ssh-keygen. Probablemente uno de estos:

ssh-keygen -m RFC4716 -i -f /Users/bfenker/.ssh/id_rsa

Use la salida como nuevo archivo de clave ( ssh-keygen ... >newkeyfile).

Editar 1:

Tenga en cuenta esto: "Esta opción leerá un archivo de clave privada (o pública) sin cifrar "

Por lo tanto, es probable que un programa que comprenda ese formato deba cambiar el archivo a uno sin frase de contraseña.

Primero debe verificar sus registros sshd. es decir

less /var/log/secure

Dependiendo del archivo de distribución de Unix con registro de seguridad puede diferir. Pero cuando encuentre si, debería indicar la razón por la que no puede iniciar sesión.

También me enfrenté a este problema recientemente. En mi caso, todos los permisos eran correctos, incluidos .ssh, el archivo rsa, el directorio de inicio y todo lo relacionado con el usuario. El problema era que tenía una clave pública generada previamente en .ssh que no se correspondía con la clave privada que estaba usando para iniciar sesión. La eliminación de la clave pública de .ssh solucionó el problema.

Estaba usando ssh-keygen para crear el directorio .ssh que resultó en esta clave de publicación y, por lo tanto, el problema.

Siento que las respuestas aquí no son muy claras. La respuesta de Mark Wagner lo cubre, pero no explica completamente la situación.

Las líneas en la salida tienen como prefijo sus niveles de depuración, lo que también da una pista de su importancia: pero los números más bajos son más significativos. El debug3:material es mucho menos importante quedebug1:

Cuando se lee el archivo de clave, ssh primero intenta analizarlo como la clave RSA en desuso (ahora llamada "RSA1"), esas claves comienzan con SSH PRIVATE KEY FILE FORMATun número de versión. Todas las nuevas claves RSA comienzan -----BEGIN RSA PRIVATE KEY-----. Aquí hay un intento de inicio de sesión en el que identityhay una antigua clave de estilo RSA1 y id_rsaun nuevo estilo.

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type 0
debug1: identity file /home/user/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
[...]
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1

En este punto, ha identificado los tipos de clave en los archivos identitycomo type 0y id_rsacomo type 1. Los otros archivos que verifica no existen y son así type -1.

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3

Como se trata del protocolo 2, la clave RSA del protocolo 1 identityse ignorará durante el intercambio de claves.

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/id_rsa (0x5622d77426a0)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))

Aquí nos recuerda los archivos clave que quiere usar. No estoy seguro de por qué no ha rechazado los archivos faltantes, solo el archivo de protocolo 1, pero ...

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
[...]
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 372 bytes for a total of 1689
debug1: Server accepts key: pkalg ssh-rsa blen 277

Y aquí ofrece la id_rsaclave y se acepta.

Entonces, en resumen, el problema en el título de la pregunta es un arenque rojo que proviene de ssh intentando múltiples formas de analizar las claves que encuentra, no un problema real con una clave.

Tuve el mismo problema en mi MacBook Pro con MacOS 10.7.5. No había nada malo con mis claves, es solo que están encriptadas (con una frase de contraseña, como se supone que debes hacer) y no estaban encriptadas por ssh correctamente. Parece que ssh-agentestá teniendo problemas.

De acuerdo con este artículo , intente esto:

1. Ponga /usr/bin/ssh-agentsus elementos de inicio de sesión (Preferencias del sistema -> Usuarios y grupos -> seleccione usuario -> Elementos de inicio de sesión). Es muy difícil navegar /usr/binen el cuadro de diálogo, por lo que el artículo sugiere hacer un enlace en su directorio de inicio ( ln -s /usr/bin/ssh-agent) que puede eliminar una vez que lo haya colocado en Elementos de inicio de sesión.

2. Salga de Terminal.app

3. Reiniciar la máquina.

4. Abra la Terminal y vuelva a intentar su comando ssh.

Funcionó para mí (al menos, lo ha hecho una vez).