SSH-Fehler: unbekannter Schlüsseltyp '----- BEGIN'

Ich habe Probleme bei der Verwendung autorisierter Schlüssel für die SSH-Anmeldung bei einem Remote-Server. Die Fehlermeldungen, die ich erhalte, sehen folgendermaßen aus:

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

Andere Fragen auf dieser Site haben ähnliche Fragen gestellt, und die Lösung bestand normalerweise darin, alle Berechtigungen auf der Clientseite zu überprüfen, was ich getan habe:

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

Ich kann den autorisierten Schlüssel für SSH in einem anderen Server und von diesem Server in SSH auf dem gewünschten Server verwenden. Dies ist eine passable Problemumgehung, die ich zu beheben versuche, aber ich denke, sie zeigt auch, dass sowohl mein Client als auch der Server in Ordnung eingerichtet sind.

Beachten Sie, dass beim erfolgreichen SSH auf einem anderen Server dieselben Fehlermeldungen angezeigt werden, die sich jedoch ab den folgenden Zeilen zu erholen scheinen:

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

Weiß jemand, warum dies in einigen Fällen funktioniert, aber nicht in dem Fall, den ich möchte? Alle anderen Vorschläge wäre sehr dankbar!

Necroquestion! Basierend auf der Tatsache, dass Sie diesen Schlüssel verwenden können, um sich bei einem anderen Server anzumelden, befindet sich @ michael-hampton auf dem richtigen Weg: Auf dem Zielserver befindet sich etwas (Firewall / TCP-Wrapper / SSHD-Konfiguration), das den Zugriff verweigert. All dieses Gerede über falsche Schlüsselformate ist ein roter Hering, der auf einer falschen Interpretation der Debug-Informationen basiert. Die Linie

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

zeigt an, dass ssh den Schlüssel verstehen konnte.

Ihr SSH-Schlüssel wird im falschen Format gespeichert. OpenSSH verwendet Schlüssel, die in einer einzelnen Zeile stehen. Sie benötigen ssh-keygenmit -iund -mOptionen, siehe man ssh-keygen. Wahrscheinlich eines davon:

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

Verwenden Sie die Ausgabe als neue Schlüsseldatei ( ssh-keygen ... >newkeyfile).

Bearbeiten 1:

Bitte beachten Sie Folgendes: "Diese Option liest eine unverschlüsselte private (oder öffentliche) Schlüsseldatei."

Wahrscheinlich muss die Datei von einem Programm, das dieses Format versteht, in eine Datei ohne Passphrase geändert werden.

Zuerst sollten Sie Ihre SSHD-Protokolle überprüfen. dh

less /var/log/secure

Abhängig von der Unix-Verteilungsdatei mit Sicherheitsprotokoll kann dies unterschiedlich sein. Wenn Sie jedoch feststellen, ob dies der Fall ist, sollte der Grund angegeben werden, aus dem Sie sich nicht anmelden können.

Ich habe mich kürzlich auch mit diesem Problem befasst. In meinem Fall waren alle Berechtigungen korrekt, einschließlich .ssh, der rsa-Datei, des Home-Verzeichnisses und allem, was mit dem Benutzer zu tun hat. Das Problem war, dass ich in .ssh einen zuvor generierten öffentlichen Schlüssel hatte, der nicht dem privaten Schlüssel entsprach, den ich für die Anmeldung verwendete. Durch Entfernen des öffentlichen Schlüssels aus .ssh wurde das Problem behoben.

Ich habe ssh-keygen verwendet, um ein .ssh-Verzeichnis zu erstellen, das zu diesem Pub-Schlüssel und damit zum Problem führte.

Ich denke, die Antworten hier sind nicht sehr klar. Mark Wagners Antwort deckt es zwar ab, erklärt aber die Situation nicht vollständig.

Den Zeilen in der Ausgabe werden ihre Debug-Ebenen vorangestellt, was auch einen Hinweis auf ihre Bedeutung gibt: Niedrigere Zahlen sind jedoch wichtiger. Das debug3:Zeug ist viel weniger wichtig alsdebug1:

Wenn die Schlüsseldatei gelesen wird, versucht ssh zuerst, sie als veralteten RSA-Schlüssel (jetzt "RSA1" genannt) zu analysieren. Diese Schlüssel beginnen mit SSH PRIVATE KEY FILE FORMATund einer Versionsnummer. Die neuen RSA-Schlüssel werden alle gestartet -----BEGIN RSA PRIVATE KEY-----. Hier ist ein Anmeldeversuch, bei dem identityes sich um einen alten RSA1-Stilschlüssel und id_rsaeinen neuen Stil handelt.

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

Zu diesem Zeitpunkt wurden die Schlüsseltypen in den Dateien identityals type 0und id_rsaals identifiziert type 1. Die anderen Dateien, die überprüft werden, existieren nicht und sind es auch 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

Da dies Protokoll 2 ist, wird der RSA-Schlüssel für Protokoll 1 beim Schlüsselaustausch identityignoriert.

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

Hier erinnert es uns an die Schlüsseldateien, die es verwenden möchte. Nicht sicher, warum es die fehlenden Dateien nicht abgelehnt hat, nur die Protokoll 1-Datei, aber ...

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

Und hier bietet es den id_rsaSchlüssel an und es wird akzeptiert.

Kurz gesagt, das Problem im Fragentitel ist ein roter Hering, der von ssh stammt und versucht, die gefundenen Schlüssel auf verschiedene Arten zu analysieren, und kein wirkliches Problem mit einem Schlüssel.

Ich hatte das gleiche Problem auf meinem MacBook Pro mit MacOS 10.7.5. An meinen Schlüsseln war nichts auszusetzen, sie sind nur verschlüsselt (mit einer Passphrase, wie Sie es tun sollten) und wurden von ssh nicht korrekt entschlüsselt. Es scheint, dass ssh-agentes Probleme gibt.

Versuchen Sie laut diesem Artikel Folgendes:

1. Geben Sie /usr/bin/ssh-agentIhre Anmeldeelemente ein (Systemeinstellungen -> Benutzer und Gruppen -> Benutzer auswählen -> Anmeldeelemente). Es ist furchtbar schwierig, /usr/binim Dialogfeld zu navigieren. In diesem Artikel wird daher vorgeschlagen, einen Link in Ihrem Home-Verzeichnis ( ln -s /usr/bin/ssh-agent) zu erstellen, den Sie entfernen können, sobald Sie ihn in die Anmeldeelemente eingefügt haben.

2. Beenden Sie Terminal.app

3. Starten Sie die Maschine neu.

4. Öffnen Sie das Terminal und wiederholen Sie den Befehl ssh.

Hat für mich gearbeitet (zumindest einmal).