Was könnte eine Nichtübereinstimmung des SFTP-Hostschlüssel-Fingerabdrucks verursachen?

Was könnte eine Nichtübereinstimmung des SFTP-Hostschlüssel-Fingerabdrucks verursachen?

Ein Remote-Benutzer hat zum ersten Mal versucht, mithilfe des „Transmit“-Clients unter Mac OS X eine Verbindung zu meinem SFTP/SSH-Server herzustellen, und hat festgestellt, dass der Host-Key-Fingerabdruck nicht mit dem erwarteten Wert übereinstimmt.

Ich habe einen Screenshot des angezeigten Fingerabdrucks und habe ihn mit der Ausgabe von ssh-keygen -lf /etc/ssh/ssh_host_dsa_keyund verglichen ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub, und er stimmt mit keinem von beiden überein.

Ich habe den Fingerabdruck auch erfolglos mit der Ausgabe von cut -d ' ' -f 2 < /etc/ssh/ssh_host_dsa_key.pub | base64 -d | sha1sumund verglichen cut -d ' ' -f 2 < /etc/ssh/ssh_host_rsa_key.pub | base64 -d | sha1sum(weil es so aussieht, als ob unterschiedliche Fingerabdruckalgorithmen verwendet werden?).

Das Meldungsfeld auf der Clientseite trägt den Titel (ins Englische übersetzt)

Unbekannter Hostschlüssel für< Hostname >

und Staaten

Der Server ist unbekannt. Der Fingerabdruck des Hostschlüssels ist< 16 Oktette >. ( Erlauben ) ( Verweigern ) [ ] Immer

Es gibt also keinen Hinweis darauf, ob ein RSA- oder DSA-Schlüssel verwendet wird oder ob zum Erstellen des Fingerabdrucks MD5 oder ein SHA-Algorithmus verwendet wird.

Der dem Remote-Benutzer angezeigte Fingerabdruck besteht aus 16 durch Doppelpunkte getrennten Oktetten und scheint daher weder SHA-224 noch eine höhere Version zu verwenden.Aktualisieren: Mir ist gerade aufgefallen, dass selbst ein SHA-1-Hash 20 Oktette hat, der angezeigte Fingerabdruck liegt also anscheinend nicht in einem SHA-Format vor.

Die Verbindung geht letztlich zum richtigen Server, denn ich kann den Login-Versuch in meinen Server-Logs sehen, wenn der Benutzer die Verbindung zulässt. Es scheint also, dass der Hostname/die IP auf der Client-Seite korrekt eingetragen ist.

Eine Verbindung zu einem anderen (völlig unabhängigen) SFTP-Server zeigt ebenfalls einen falschen Fingerabdruck (allerdings einen anderen als beim ersten Server).

Wenn ich versuche, von einem anderen Host aus (oder lokal vom Server selbst) mithilfe von OpenSSH eine Verbindung zum Server herzustellen, wird mir der richtige Fingerabdruck angezeigt (der MD5-Fingerabdruck für den RSA-Hostschlüssel).

Auf dem Server läuft Debian 6 LTS mit dem Standard-OpenSSH-Server.

Was könnte die Ursache für diese Fingerabdruck-Nichtübereinstimmung sein? Wie kann ich dieses Problem beheben?

Antwort1

Wenn die Verbindung zum ersten Mal hergestellt wird, spielt es keine Rolle, ob eine Nichtübereinstimmung vorliegt. Der Client hatte einfach einen alten, nicht verwandten Eintrag, der zufällig mit demselben Hostnamen oder derselben IP-Adresse verknüpft war. Löschen Sie ihn einfach mit:

ssh-keygen -R $name_or_ip

Nachdem Sie das getan haben, sollte beim nächsten Verbindungsaufbau auf jeden Fall angezeigt werden, ob es sich um RSA, ECDSA usw. handelt. Wenn nicht, versuchen Sie, einen geeigneten Client wie den OpenBSD OpenSSH-Client zu verwenden, der unter Linux Standard ist, oder versuchen Sie es mit -v (oder -vvvv usw., ausführliche Optionen). Überprüfen und akzeptieren Sie dann den neuen Schlüssel. Das Schlüsselfingerabdruckformat in alten Clients ist MD5 (und in neuen ist es SHA256, in einem seltsamen Base64-Format statt ASCII-Hex), und der richtige Weg, um den Fingerabdruck auf der Serverseite zu erhalten, ist:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Antwort2

Es stellte sich heraus, dass das verwendete FTP-Programm nicht Transmit, sondern Cyberduck 4.5.1 war. Das Problem mit dem falschen Fingerabdruck war bereits bekannt alsFalscher Host-Key-Fingerabdruck. Durch das Update auf die neuste Version wurde dieses Problem behoben und der angezeigte Fingerabdruck ist nun korrekt.

verwandte Informationen