Ich bin neu im Sicherheitsbereich und wollte den Grund für den Fehler verstehen, der bei mir auftritt:
com.jcraft.jsch.JSchException: UnknownHostKey: 127.0.0.1. RSA-Schlüsselfingerabdruck ist a2:39:3f:44:88:e9:1f:d7:d1:71:f4:85:98:fb:90:dc bei com.jcraft.jsch.Session.checkHost(Session.java:797) bei com.jcraft.jsch.Session.connect(Session.java:342) bei com.jcraft.jsch.Session.connect(Session.java:183) bei FileTransfer.main(FileTransfer.java:37). Prozess wurde mit Exitcode 0 beendet.
was ist mit `unknownHostKey: 127.0.0.1 gemeint. RSA-Schlüssel
Fingerabdruck ist a2:39:3f:44:88:e9:1f:d7:d1:71:f4:85:98:fb:90:dc`
known_hosts
Um diesen Fehler zu beheben, muss ich eine Datei mit dem Namen „Datei“ festlegen :
Ich habe versucht, es wie folgt einzurichten:
127.0.0.1
Aber das funktioniert nicht. Habe ich falsch verstanden, was mit einer known_hosts
Datei gemeint ist?
Antwort1
Der Verdienst für diese Antwort geht anGillesvon demStackExchange-Sicherheitssite, als sein/ihrPostDas Erklären known_hosts
von authorized_keys
Dateien ist ein guter Ausgangspunkt zum Verständnis dieser Komponente von SSH/SFTP.
Siehe unten:
Mit der known_hosts
Datei kann der Client den Server authentifizieren, um sicherzustellen, dass er keine Verbindung zu einem Betrüger herstellt. Mit der authorized_keys
Datei kann der Server den Benutzer authentifizieren.
Serverauthentifizierung
Eines der ersten Dinge, die passieren, wenn die SSH-Verbindung hergestellt wird, ist, dass der Server seinen öffentlichen Schlüssel an den Client sendet und beweist (dankPublic-Key-Kryptographie) an den Client, dass er den zugehörigen privaten Schlüssel kennt. Dadurch wird der Server authentifiziert: Wenn dieser Teil des Protokolls erfolgreich ist, weiß der Client, dass der Server derjenige ist, für den er sich ausgibt.
Der Client kann prüfen, ob es sich um einen bekannten Server handelt und nicht um einen betrügerischen Server, der sich als der richtige ausgeben will. SSH bietet nur einen einfachen Mechanismus zur Überprüfung der Legitimität des Servers: Es merkt sich Server, mit denen Sie bereits verbunden waren, in der ~/.ssh/known_hosts
Datei auf dem Client-Rechner (es gibt auch eine systemweite Datei /etc/ssh/known_hosts
). Wenn Sie sich zum ersten Mal mit einem Server verbinden, müssen Sie auf andere Weise prüfen, ob der vom Server präsentierte öffentliche Schlüssel wirklich der öffentliche Schlüssel des Servers ist, mit dem Sie sich verbinden wollten. Wenn Sie den öffentlichen Schlüssel des Servers haben, mit dem Sie sich verbinden möchten, können Sie ihn ~/.ssh/known_hosts
auf dem Client manuell hinzufügen.
Kann übrigens known_hosts
jeden Typ von öffentlichem Schlüssel enthalten, der von der SSH-Implementierung unterstützt wird, nicht nur DSA (auch RSA und ECDSA).
Die Authentifizierung des Servers muss erfolgen, bevor Sie vertrauliche Daten an ihn senden. Insbesondere wenn die Benutzerauthentifizierung ein Kennwort erfordert, darf das Kennwort nicht an einen nicht authentifizierten Server gesendet werden.
Benutzerauthentifizierung
Der Server lässt einen Remote-Benutzer nur dann einloggen, wenn dieser nachweisen kann, dass er das Recht hat, auf dieses Konto zuzugreifen. Je nach Konfiguration des Servers und Wahl des Benutzers kann der Benutzer eine von mehreren Arten von Anmeldeinformationen vorlegen (die folgende Liste ist nicht vollständig).
- Der Benutzer kann das Kennwort für das Konto eingeben, bei dem er sich anmelden möchte. Der Server überprüft dann, ob das Kennwort korrekt ist.
- Der Benutzer kann einen öffentlichen Schlüssel vorlegen und beweisen, dass er den privaten Schlüssel besitzt, der mit diesem öffentlichen Schlüssel verknüpft ist. Dies ist genau dieselbe Methode, die zur Authentifizierung des Servers verwendet wird, aber jetzt versucht der Benutzer, seine Identität zu beweisen, und der Server überprüft dies. Der Anmeldeversuch wird akzeptiert, wenn der Benutzer beweist, dass er den privaten Schlüssel kennt und der öffentliche Schlüssel in der Autorisierungsliste des Kontos (
~/.ssh/authorized_keys
auf dem Server) steht. - Bei einer anderen Methode wird ein Teil der Authentifizierungsarbeit des Benutzers an den Client-Rechner delegiert. Dies geschieht in kontrollierten Umgebungen wie Unternehmen, wenn viele Rechner dieselben Konten teilen. Der Server authentifiziert den Client-Rechner mit demselben Mechanismus, der auch umgekehrt verwendet wird, und verlässt sich dann auf den Client, um den Benutzer zu authentifizieren.