☰

OpenSSH akzeptiert keine ECDSA-Schlüssel

tag-icon • tag-icon ssh
OpenSSH akzeptiert keine ECDSA-Schlüssel

Ich habe gerade einen ECDSA-Schlüssel generiert mit ssh-keygen:

ssh-keygen -t ecdsa -b 521

Anschließend habe ich diesen Schlüssel auf meinen Server kopiert:

cat .ssh/id_ecdsa.pub | ssh myserver "tee -a .ssh/authorized_keys"

Ich habe überprüft, ob mein Schlüssel in der Datei ist.

Beim Verbindungsversuch wird diese jedoch abgelehnt:

ssh -v -i .ssh/id_ecdsa myserver

Protokolle:

OpenSSH_5.9p1 Debian-5ubuntu1.1, 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 myserver [192.168.1.1] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_ecdsa type 3
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-521
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-521
debug1: identity file .ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 10:27:b8:78:2c:e1:e3:42:8e:e3:66:c4:cc:4e:f1:c0
debug1: Host 'myserver' is known and matches the RSA host key.
debug1: Found key in /home/naftuli/.ssh/known_hosts:73
debug1: ssh_rsa_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
debug1: Next authentication method: publickey
debug1: Offering ECDSA public key: .ssh/id_ecdsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Folgendes habe ich in den Serverprotokollen gefunden:

auth.info sshd[13874]: userauth_pubkey: unsupported public key algorithm: ecdsa-sha2-nistp521 [preauth]

Sowohl mein Client als auch der Server verwenden OpenSSH. Die OpenSSH-Version des Servers ist OpenSSH 6.1, die OpenSSH-Version meines Clients ist OpenSSH 5.9.

Wie kann ich feststellen, welche Schlüsselalgorithmen von meinem Server unterstützt werden?

Antwort1

Wie viele andere eingebettete Systeme verwendet OpenWrtAbonnierenals SSH-Server, nicht das schwerere OpenSSH, das man häufig auf Linux-Systemen findet. Ältere Versionen von Dropbear unterstützen nur RSA- und DSA-Schlüssel; die Unterstützung für ECDSA wurde erst hinzugefügtVersion 2013.62(das erst vor ein paar Tagen erschienen ist).

Es sollte bald in Barrier Breaker (Stamm) angezeigt werden; Sie werden es jedoch nicht in Attitude Adjustment sehen.

Antwort2

ecdsawird unterstützt vonopenssh-server Version 5.7. Welche Version des OpenSSH-Servers verwenden Sie? Führen Sie „Aus“, dpkg -l | grep openssh-server | awk '{print $3}' | cut -d: -f2um die Version zu ermitteln.

Antwort3

Wenn Ihr SystemRed Hat Enterprise Linux 6.4(oder älter) oderFedora 19(oder älter), beachten Sie, dass ECDSA von dort entfernt wurde. Ich habe keine Einzelheiten, warum das so war (vielleicht rechtliche Gründe):https://www.mail-archive.com/[email geschützt]/msg00755.html

Antwort4

Ich lasse das hier, weil mir das passiert ist:

Tag 1: Beim Einrichten einer neuen Maschine habe ich die Schlüssel kopiert – zuerst meine – und konnte mich problemlos anmelden.

Tag 2: Ich kann mich mit meinem ed25519-Schlüssel nicht anmelden. Was? Ich füge einen RSA-Schlüssel hinzu; es funktioniert. Ich generiere einen neuen ed25519-Schlüssel undEsfunktioniert ... aber mein altes nicht. WTF?

Es stellte sich heraus, dass ich nach dem Testen meinen Schlüssel als Backup in root's .ssh/authorized_keys installiert hatte ... und vergessen hatte, die Berechtigungen für diese Datei zu korrigieren. OpenSSH hat meinen Schlüssel also auf die schwarze Liste gesetzt, sodass ich mich nicht anmelden konnte. Durch das Korrigieren der Berechtigungen für /root/.ssh/authorized_keys konnte ich mich anmeldenals mein Benutzer.

verwandte Informationen