14
SSH-Login mit falschem Hostkey
Es gibt einen SSH-Client, der sich per Key auf meinem SSH-Server anmeldet. (Zumindest tat er das vor dem Serverwechsel)
Ich musste den Server neu aufsetzen und dabei hat dieser einen neuen Hostkey erhalten.
Nun kann sich der Client nicht mehr anmelden...
Leider habe ich keine Möglichkeit, den neuen Hostkey auf dem Client hinzuzufügen bzw. die Hostkeyprüfung dort abzuschalten. Er versucht nun zyklisch eine Verbindung herzustellen, was natürlich nicht gelingt.
Besteht eine Möglichkeit, diesen Client temporär auf den Server zu lassen, damit ich einen Zugang erhalte?
(Sobald er online ist, kann ich ihn remote administrieren)
Uwe
Ich musste den Server neu aufsetzen und dabei hat dieser einen neuen Hostkey erhalten.
Nun kann sich der Client nicht mehr anmelden...
Leider habe ich keine Möglichkeit, den neuen Hostkey auf dem Client hinzuzufügen bzw. die Hostkeyprüfung dort abzuschalten. Er versucht nun zyklisch eine Verbindung herzustellen, was natürlich nicht gelingt.
Besteht eine Möglichkeit, diesen Client temporär auf den Server zu lassen, damit ich einen Zugang erhalte?
(Sobald er online ist, kann ich ihn remote administrieren)
Uwe
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 63871001051
Url: https://administrator.de/contentid/63871001051
Printed on: April 27, 2024 at 06:04 o'clock
14 Comments
Latest comment
Nur, indem du den alten Hostkey auf dem Server einspielst. Solange wird der Client deinem neuen Key nicht vertrauen und die Verbindung sofort wieder trennen.
1
Besteht eine Möglichkeit, diesen Client temporär auf den Server zu lassen
...oder indem du in der SSH Server Konfigurationsdatei unter "/etc/ssh/sshd_config" wieder den Username/Passwort Login erlaubst.PasswordAuthentication und ChallengeResponseAuthentication jeweils auf YES setzen.
Das hebelt dann aber dein sicheres Login mit einem Key aus und öffnet den Server für Passwort Attacken. Frage ob du das wirklich willst?!
Eine andere Option gibt es nicht. Logisch, denn der Key soll ja gerade vor solcherart Manipulationen schützen um den Zugang sicherer zu machen. Idealerweise mit fail2ban sofern der SSH Server öffentlich erreichbar ist.
Siehe zu der Thematik auch hier.
Ich werde:
Tschau
Uwe
PasswordAuthentication und ChallengeResponseAuthentication jeweils auf YES setzen.
versuchen, allerdings eingeschränkt auf die Source-IP (Match Address ...)Tschau
Uwe
Wenn es das denn war bitte deinen Thread dann auch als erledigt markieren!
How can I mark a post as solved?
How can I mark a post as solved?
...oder indem du in der SSH Server Konfigurationsdatei unter "/etc/ssh/sshd_config" wieder den Username/Passwort Login erlaubst.
Und das brauchst Du ja nur für ein einziges Login. Danach sollte sich der Hostkey aktualisert haben und wenn Du den Pubkey auf dem Server hinterlegt hast, der Client sich auch per Key wieder einloggen können.Viele Grüße, commodity
Leider bekomme ich auch per Username/Passwort keine Verbindung. 8-(
(Von einem anderen Client aus klappt es)
Schade...
Tschau
Uwe
(Von einem anderen Client aus klappt es)
Schade...
Tschau
Uwe
Was ist das denn für ominöser SSH Client?
Es ist doch sehr hilfreich das zu wissen. Springt einem förmlich ins Auge
Es ist doch sehr hilfreich das zu wissen. Springt einem förmlich ins Auge
2
Leider habe ich keine Möglichkeit, den neuen Hostkey auf dem Client hinzuzufügen
Auf die known_hosts hast du keinen Zugriff?In
~/.ssh/known_hosts am Client die Zeile für den Host entfernen, oder per Option -o "StrictHostKeyChecking=off".Oder eben SSH-Client zurücksetzen wenn der keine andere Möglichkeit bietet den Hostkey zu aktualisieren, kann ich mir aber ehrlich gesagt nicht vorstellen.
Gruß pp.
3
Das was @puderpader sagt.
Ich fürchte, einige verwechseln "Host-Key" mit "Public Key für Authentifizierung".
Um das vielleicht nochmal zu klären:
Der Host-Key bei SSH ist quasi das SSL-Zertifikat des Servers. Bei der ersten Verbindung muss man es explizit akzeptieren, dann ist Ruhe. Ändert sich der Host-Key/Zertifikat misstraut der Client dem Server und bricht die Verbindung ab.
Das kann prinzipbedingt, wie bei SSL auch, nicht durch den Server gesteuert werden. Das wäre ja ziemlich sinnlos, wenn der Server dem Client einreden kann dass er der Verbindung vertrauen soll.
Deshalb gibt es nur die Möglichkeit, den alten Key wiederherzustellen oder den Client manuell dazu zu bringen dem neuen Key zu vertrauen.
Da hilft keine Einstellung am Server, erst recht nichts zu Login mit Passwort.
Ich fürchte, einige verwechseln "Host-Key" mit "Public Key für Authentifizierung".
Um das vielleicht nochmal zu klären:
Der Host-Key bei SSH ist quasi das SSL-Zertifikat des Servers. Bei der ersten Verbindung muss man es explizit akzeptieren, dann ist Ruhe. Ändert sich der Host-Key/Zertifikat misstraut der Client dem Server und bricht die Verbindung ab.
Das kann prinzipbedingt, wie bei SSL auch, nicht durch den Server gesteuert werden. Das wäre ja ziemlich sinnlos, wenn der Server dem Client einreden kann dass er der Verbindung vertrauen soll.
Deshalb gibt es nur die Möglichkeit, den alten Key wiederherzustellen oder den Client manuell dazu zu bringen dem neuen Key zu vertrauen.
Da hilft keine Einstellung am Server, erst recht nichts zu Login mit Passwort.
2
Korrekt gesehen (und auch von mir übersehen). Das Problem liegt genau hier:
Ganz gleich ob Pubkey-Auth oder Password-Auth, der Client muss nach Wechsel des Hostkeys zwangsläufig fragen, ob die auf Seiten des Hosts erfolgte Änderung akzeptiert wird. Wenn aber "keine Möglichkeit" besteht, mit dem Client zu interagieren kann natürlich dort nichts akzeptiert werden.
Der TO muss also eine Möglichkeit schaffen, einen SSH-Login auf dem Client anzustoßen, bei dem er den neuen Hostkey bestätigen kann. Ich sehe auch nicht, was daran so schwierig sein sollte. Solange man irgendwie auf den Client kommt (vor Ort, RDP, VNC, SSH...), kann man das durchführen. Wenn der Client unerreichbar ist, wird das hingegen nichts. Das wäre dann aber auch ein administratives Fehlkonstrukt, da ein technischer Defekt ja offenbar nicht vorliegt.
Viele Grüße, commodity
Leider habe ich keine Möglichkeit, den neuen Hostkey auf dem Client hinzuzufügen bzw. die Hostkeyprüfung dort abzuschalten.
Ganz gleich ob Pubkey-Auth oder Password-Auth, der Client muss nach Wechsel des Hostkeys zwangsläufig fragen, ob die auf Seiten des Hosts erfolgte Änderung akzeptiert wird. Wenn aber "keine Möglichkeit" besteht, mit dem Client zu interagieren kann natürlich dort nichts akzeptiert werden.
Der TO muss also eine Möglichkeit schaffen, einen SSH-Login auf dem Client anzustoßen, bei dem er den neuen Hostkey bestätigen kann. Ich sehe auch nicht, was daran so schwierig sein sollte. Solange man irgendwie auf den Client kommt (vor Ort, RDP, VNC, SSH...), kann man das durchführen. Wenn der Client unerreichbar ist, wird das hingegen nichts. Das wäre dann aber auch ein administratives Fehlkonstrukt, da ein technischer Defekt ja offenbar nicht vorliegt.
Viele Grüße, commodity
1
Danke für die weiteren Anmerkungen.
Der Client ist netzwerktechnisch von mir leider nicht erreichbar.
Es bleibt also nur das manuelle Akzeptieren des neuen Hostkey auf Clientseite bzw. das dortige Abschalten der Hostkeyprüfung.
Uwe
Der Client ist netzwerktechnisch von mir leider nicht erreichbar.
Es bleibt also nur das manuelle Akzeptieren des neuen Hostkey auf Clientseite bzw. das dortige Abschalten der Hostkeyprüfung.
Uwe
Der Client ist netzwerktechnisch von mir leider nicht erreichbar.
Briefpost mit einem USB Stick dadrin oder einer CD-Rom tut es ja auch! 
Scheint ja echt ein Staatsgeheimnis zu sein um welchem Client es sich nun handelt ...🤫
Dann gib dem Verantwortlichen für den Client bescheid das er den alten zwischengespeicherten Fingerprint des Hosts auf deinen aktuellen aktualisiert oder entfernt, wenn du deine alten Keys des Servers nicht aus einem Backup wiederherstellen kannst/willst.
Dann gib dem Verantwortlichen für den Client bescheid das er den alten zwischengespeicherten Fingerprint des Hosts auf deinen aktuellen aktualisiert oder entfernt, wenn du deine alten Keys des Servers nicht aus einem Backup wiederherstellen kannst/willst.
2
Das ist kein "Staatsgeheimnis", aber ein relativ altes IoT Device, das sich per SSH mit einem zentralen Server verbindet und auf diesem Weg ein Remote-Login ermöglicht (wegen CGN im Mobilfunknetz).
Ich habe das Problem inzwischen lösen können!
Nach temporärer Aktivierung des alten Server Hostkeys auf dem SSH-Server hat sich der Client wieder verbunden und ich konnte die Konfiguration anpassen.
Tschau
Uwe
Ich habe das Problem inzwischen lösen können!
Nach temporärer Aktivierung des alten Server Hostkeys auf dem SSH-Server hat sich der Client wieder verbunden und ich konnte die Konfiguration anpassen.
Tschau
Uwe