it-swarm-eu.dev

ECDSA-Schlüssel geändert, SSH jetzt unsicher?

Ich betreibe einige unkritische Ubuntu-Server in meinem Studentenwohnheim. Schalten Sie sie vor der Pause aus, kehren Sie mit SSH zurück und erhalten Sie eine Warnung, dass sich die ECDSA-Schlüssel geändert haben.

Es sah ziemlich ähnlich aus

Warning: the ECDSA Host key for '<snip>' differs from the key for the IP address '<snip>'
Offending key for IP in /home/<snip>/.ssh/known_hosts:14
Matching Host key in /home/<snip>/.ssh/known_hosts:12
Are you sure you want to continue connecting (yes/no)?

Dies sieht viel weniger beängstigend aus als der Fehler, bei dem die Serveridentität geändert wurde. Ich mache mir also keine allzu großen Sorgen, aber was würde dazu führen, dass sich dies ändert? Sollte ich mir darüber Sorgen machen?

29
TheLQ

Wenn Sie zum ersten Mal eine Verbindung zu einem bestimmten SSH-Server herstellen, erhalten Sie die übliche Frage mit dem Schlüsselfingerabdruck. Anschließend speichert der SSH-Client eine Kopie des öffentlichen Serverschlüssels in der Datei .ssh/known_hosts. Der SSH-Client speichert jedoch tatsächlich zwei Schlüssel: einen für den Server Name und einen für den Server [~ # ~] ip [~ # ~ ].

Angenommen, der Server foo.example.com Hat die IP 10.0.0.8. Bei Ihrer ersten Verbindung (ssh foo.example.com) Erhält der SSH-Client den öffentlichen Serverschlüssel, zeigt den Fingerabdruck (einen Hash des öffentlichen Schlüssels) an, fordert eine Bestätigung an und speichert ihn im known_hosts Datei zwei Zuordnungen, eine für foo.example.com, die andere für 10.0.0.8, die beide auf denselben öffentlichen Schlüssel verweisen.

Wenn Sie wieder eine Verbindung zum selben Server herstellen, überprüft SSH die beiden Zuordnungen. Wenn die erste Zuordnung (die für den Namen) einen öffentlichen Schlüssel ergibt, der sich von dem in known_hosts Aufgezeichneten unterscheidet, erhalten Sie die beängstigende Fehlermeldung mit GROSSBUCHSTABEN (so gelingt es, beängstigend zu sein) Der Client weigert sich, eine weitere Verbindung herzustellen (die Nachricht ist also nicht nur beängstigend, sondern auch ziemlich unpraktisch).

Eine andere Situation ist, wenn das erste Mapping übereinstimmt:

  • Der Benutzer gibt Folgendes ein: ssh foo.example.com.
  • Das DNS-System löst diesen Namen in IP 10.0.0.8 Auf.
  • Der SSH-Client stellt eine Verbindung zu diesem Computer her und erhält den öffentlichen Schlüssel des SSH-Servers.
  • Der erhaltene öffentliche Schlüssel stimmt mit dem in .ssh/known_hosts Unter dem Eintrag foo.example.com Gefundenen überein.
  • [~ # ~] aber [~ # ~] der erhaltene öffentliche Schlüssel stimmt [~ # ~] nicht [~ # ~] mit dem in überein .ssh/known_hosts Unter dem Eintrag 10.0.0.8.

In diesem Fall erhalten Sie genau die Nachricht, die Sie in Ihrer Frage anzeigen. Der SSH-Client hat die Gewissheit, dass Sie mit dem vorgesehenen Server sprechen - der öffentliche Schlüssel stimmt mit dem für denselben Server aufgezeichneten überein name - aber etwas stimmt immer noch nicht, daher die Warnung und die Bestätigungsaufforderung.

Dies kann passieren, wenn sich die Server-IP geändert hat. Nehmen wir im obigen Beispiel an, dass foo.example.com Letzte Woche IP 10.0.0.7 Hatte, aber bar.example.com IP 10.0.0.8 Hatte. Zu diesem Zeitpunkt haben Sie eine Verbindung zu beiden hergestellt. Aber am letzten Wochenende entschied ein Systemadministrator mit einer leichten Zwangsstörung, dass einige IP-Adressen geändert werden mussten, damit er effizientere, regelmäßigere und mathematisch elegantere Netzwerkregeln einrichten konnte. Also "verschob er Server" und setzte bar.example.com Auf IP 10.0.0.16 Und foo.example.com Auf 10.0.0.8. Unser Freund, der Systemadministrator, hat den DNS pflichtbewusst so konfiguriert, dass er die neue IP meldet. Jetzt sind wir am Montag und Sie möchten sich wieder verbinden. Ihr SSH-Client spricht mit dem DNS, erhält die neue IP für foo.example.com Und alles ist in Ordnung, außer dass der aufgezeichnete Schlüssel für 10.0.0.8 Nicht mit dem übereinstimmt öffentlicher Schlüssel von foo.example.com: In der Tat enthält Ihre known_hosts - Datei eine Kopie des öffentlichen Schlüssels von bar.example.com, der unter der IP 10.0.0.8 aufgeführt ist letzte Woche war die IP von bar, nicht die von foo.

Ein Systemadministrator mit Zwangsstörung ist für dieses Szenario nicht unbedingt erforderlich. Dies kann auch bei dynamischen IP-Setups oder in einigen Fällen beim Lastausgleich auftreten.

Lösung : Verwenden Sie einen Texteditor und entfernen Sie den fehlerhaften Eintrag aus Ihrem known_hosts (In Ihrem Fall Zeile 14). Sie können auch den Befehl ssh-keygen -R <Host> Verwenden, um den jeweiligen Eintrag zu entfernen. Wenn Sie das nächste Mal eine Verbindung herstellen, zeigt der Client eine weitere Warnung an (diesmal beschwert er sich über die Abwesenheit eines aufgezeichneten öffentlichen Schlüssels für die Ziel-IP), aber diese wird fast unbemerkt vorbeifliegen, weil Es wird überhaupt keine Eingabeaufforderung geben. Der SSH-Client zeichnet dann den öffentlichen Schlüssel erneut in known_hosts Auf und stellt die Dinge richtig, zumindest bis der Systemadministrator Stimmen hört wieder.

Deaktivieren Sie alternativ die Host-IP-Prüfung im SSH-Client, indem Sie die Option CheckHostIP auf no setzen (im systemweiten /etc/ssh/ssh_config Oder in Ihrem .ssh/config). oder direkt in der Kommandozeile: ssh -o CheckHostIP=no foo.example.com). Host-IP-Überprüfungen sind nützlich, um abnormale Situationen wandernder Servernamen zu erkennen, aber für einige Systemadministratoren ist Server-IP-Jongleur völlig "normal".

41
Tom Leek

Angenommen, ich vermute das <snip> Teile richtig, sieht aus wie der Hostname (example.com) wird jetzt in eine andere IP aufgelöst als zuvor.

Ob Sie sich darüber Sorgen machen müssen oder nicht, ist ohne weitere Informationen schwer zu sagen. Welche Form hat der Hostname? Ist es ein FQDN? Wird es mit DNS gelöst? Haben Sie DNS-Änderungen vorgenommen? Diese Art von Informationen.

Es ist wahrscheinlich besser, wenn Sie Ihre Hostnamen und IPs durch Beispiele ersetzen (example.com, example.net, example.org und anything-you-want.test sind gut für Hostnamen, private IPs wie 192.168.foo.bar oder 10.foo.bar.baz sind gut für IPs), so ist die Befehlsausgabe leichter zu interpretieren. Sie können dies auch verwenden, um anzugeben, ob sich zwei Domänen in derselben TLD befinden, ob sich zwei IPs im selben Subnetz befinden usw. Dies ist also sehr nützlich.

10
Jerome Baum

Wenn die IP nicht verschoben und das openssh-Server-Paket nicht aktualisiert und ein neuer Host-Schlüssel generiert wurde, was ist dann passiert?

Sie können zwar die Host-Schlüsselprüfung deaktivieren, dies ist jedoch keine Übung, mit der ich beginnen würde.

Was passiert zu sein scheint, ist, dass ssh jetzt ein anderes Host-Schlüsselsystem verwendet (ECDSA vs DSA oder RSA) und die Warnung macht uns darauf aufmerksam.

5
Lars Nordin