Errore SSH: tipo di chiave sconosciuto '----- BEGIN'

Sto riscontrando problemi nell'utilizzo delle chiavi autorizzate per l'accesso SSH a un server remoto. I messaggi di errore che ricevo sono simili al seguente:

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

Altre domande su questo sito hanno pubblicato domande simili e la soluzione era di solito ricontrollare tutte le autorizzazioni sul lato client, cosa che ho fatto:

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

Sono in grado di utilizzare la chiave autorizzata per SSH in un altro server e da questo server SSH nel server che desidero. Questa è una soluzione accettabile che sto cercando di risolvere, ma penso che dimostri anche che sia il mio client che il server sono impostati correttamente.

Si noti che quando SSH riesce correttamente in un altro server, ricevo gli stessi messaggi di errore, ma sembra ripristinarsi a partire dalle righe:

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

Qualcuno sa perché questo funziona in alcuni casi, ma non nel caso che voglio? Qualsiasi altro suggerimento sarebbe molto apprezzato!

Necroquestion! In base al fatto che è possibile utilizzare questa chiave per accedere a un altro server @ michael-hampton è sulla strada giusta: c'è qualcosa (firewall / tcp wrappers / sshd config) sul server di destinazione che sta negando l'accesso. Tutto questo parlare di formati chiave errati è un'aringa rossa basata su un'interpretazione errata delle informazioni di debug. La linea

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

indica che ssh è stato in grado di comprendere la chiave.

La chiave SSH è memorizzata nel formato errato. OpenSSH usa chiavi che sono inserite in una sola riga. È necessario ssh-keygencon -ie le -mopzioni, vedere man ssh-keygen. Probabilmente uno di questi:

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

Utilizzare l'output come nuovo file chiave ( ssh-keygen ... >newkeyfile).

Modifica 1:

Ricorda: "Questa opzione leggerà un file di chiave privata (o pubblica) non crittografato "

Quindi probabilmente il file deve essere cambiato in uno senza passphrase da un programma che capisce quel formato.

Per prima cosa dovresti controllare i tuoi log sshd. vale a dire

less /var/log/secure

A seconda del file di distribuzione unix con registro di sicurezza potrebbe essere diverso. Ma quando scopri se, dovrebbe indicare il motivo per cui non riesci ad accedere.

Ho anche affrontato questo problema di recente. Nel mio caso tutte le autorizzazioni erano corrette, inclusi .ssh, il file rsa, la directory home e tutto ciò che riguardava l'utente. Il problema era che avevo una chiave pubblica precedentemente generata in .ssh che non corrispondeva alla chiave privata che stavo usando per il login. La rimozione della chiave pubblica da .ssh ha risolto il problema.

Stavo usando ssh-keygen per creare la directory .ssh che ha portato a questa chiave pub e quindi al problema.

Sento che le risposte qui non sono molto chiare. La risposta di Mark Wagner lo copre, ma non spiega completamente la situazione.

Le linee nell'output hanno il prefisso con i loro livelli di debug, il che dà anche un suggerimento per il loro significato: ma numeri più bassi sono più significativi. Le debug3:cose sono molto meno importanti didebug1:

Quando viene letto il file delle chiavi, ssh tenta innanzitutto di analizzarlo come chiave RSA obsoleta (ora denominata "RSA1"), quelle chiavi iniziano con SSH PRIVATE KEY FILE FORMATun numero di versione. Le nuove chiavi RSA iniziano tutte -----BEGIN RSA PRIVATE KEY-----. Ecco un tentativo di accesso in cui si identitytrova una vecchia chiave di stile RSA1 ed id_rsaè un nuovo stile.

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

A questo punto ha identificato i tipi di chiave nei file identitycome type 0e id_rsacome type 1. Gli altri file che controlla non esistono e sono quindi 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

Poiché si tratta del protocollo 2, la chiave RSA del protocollo 1 identityverrà ignorata durante lo scambio di chiavi.

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))

Qui ci ricorda i file chiave che vuole usare. Non so perché non abbia rifiutato i file mancanti, solo il file protocollo 1, ma ...

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

E qui offre la id_rsachiave ed è accettato.

Quindi, in breve, il problema nel titolo della domanda è un'aringa rossa che proviene da ssh che prova diversi modi per analizzare le chiavi che trova, non un vero problema con una chiave.

Ho avuto lo stesso problema sul mio MacBook Pro con MacOS 10.7.5. Non c'era niente di sbagliato nelle mie chiavi, è solo che sono crittografate (con una passphrase, come dovresti fare) e non erano state crittografate correttamente da ssh. Sembra che ssh-agentstia avendo problemi.

Secondo questo articolo , prova questo:

1. Inserisci /usr/bin/ssh-agentgli elementi di accesso (Preferenze di Sistema -> Utenti e gruppi -> seleziona utente -> Elementi di accesso). È terribilmente difficile navigare /usr/binnella finestra di dialogo, quindi l'articolo suggerisce di creare un collegamento nella directory home ( ln -s /usr/bin/ssh-agent) che è possibile rimuovere dopo averlo inserito negli elementi di accesso.

2. Esci da Terminal.app

3. Riavvia la macchina.

4. Apri Terminale e riprova il tuo comando ssh.

Ha funzionato per me (almeno, una volta).