Gibt es eine Weise, die ich das strenge Host - Schlüssel Kontrolle Verhalten halten auf, aber es habe überprüft nur den neuen Schlüssel des Servers (die für den Host effektiv bereits eine eindeutige Identität ist), ohne es auch die Hostnamen / IP unter Berücksichtigung?
Ich habe mehrere persönliche Mobil- / Roaming-Geräte: Telefone, Laptops, mehr Telefone, die als Taschencomputer usw. verwendet werden, und ich verwende routinemäßig SSH zwischen ihnen, wobei ich die IP-Adresse anstelle des Hostnamens verwende.
Jedes Mal, wenn ich in einem neuen Netzwerk lande (normalerweise jemandes Haus / Büro / öffentliches WLAN) oder DHCP-Leases in einem vorhandenen Netzwerk ablaufen, werden die IP-Adressen dieser Geräte umgestellt und führen zu einer oder beiden der folgenden Situationen:
Die gleiche Host mit einem unveränderten Host - Schlüssel ist in einem anderen Ort - so sshmich fordert die gleiche Host - Taste bestätigt erneut für die neue IP.
Ein neuer Host erhält dieselbe IP-Adresse wie ein zuvor verbundener Host (der vorherige Host ist jedoch gerade noch unter einer anderen IP-Adresse). Wenn er also versucht, eine Verbindung zum neuen Host sshherzustellen, wird er als der bekannte Fehler behandelt verhindert, dass eine Verbindung hergestellt wird, und das Problem zu beheben erfordert, dass ich entweder mehrere bekannte Hosts-Dateien mit Konfigurationsoptionen verwalten oder die bekannte Host-Schlüsselzuordnung für den vorherigen Host verlieren.
Ich hätte gerne eine Möglichkeit, die automatische Überprüfung des Host-Schlüssels beizubehalten, aber in meiner Anwendung ist es bedeutungslos, dem Server selbst den Hostnamen / die IP-Adresse zuzuordnen, so dass:
Derselbe Host-Schlüssel, der für einen anderen Namen / eine andere IP-Adresse angezeigt wird, sollte automatisch als bekannter Host akzeptiert werden.
Ein anderer Host-Schlüssel an einer zuvor bekannten IP-Adresse sollte den Ja / Nein-Dialog für einen neuen Schlüssel verursachen.
Anders ausgedrückt, ich würde gerne known_hosts geprüft werden, als wäre es nur eine Liste bekannter Schlüssel, anstatt einer Liste bekannter (/ IP) <-> - Tastentupel.
Diesen Tangens einfach vorwegnehmen:
Es würde keinen wirklichen Sicherheitsverlust geben, wenn SSH den Hostnamen / die IP-Adresse ignorieren könnte und einfach entscheiden sollte, ob der Schlüssel entweder neu oder bekannt ist, da der Hostschlüssel des Servers bereits über eine eindeutige Kennung für den Server verfügt, wie wir kann erhalten, unabhängig davon, unter welchem Namen / IP-Adresse sich der Server gerade befindet.
Der einzige Unterschied im Fall einer MitM wäre, dass ich die Ja / Nein-Eingabeaufforderung anstelle der Verbindung abbräuchte, aber trotzdem würde ich sofort wissen, dass etwas nicht in Ordnung war, da ich eine Verbindung zu einem Gerät herstellen würde, dessen Host-Schlüssel verwendet wird Ich erwarte, bekannt zu sein.
DNS gilt nicht, da es sich um ein Umschalten zwischen verschiedenen Netzwerken und häufig privaten IP-Adressen im LAN usw. handelt.
/etc/hosts Tweaks wäre nur schmerzhaft, wenn ich das Netzwerk oft wechseln würde.
Ich verwende keine Auto-Discovery- / Eigenwerbungstechnologien wie mDNS / ZeroConf / Bonjour, da einige dieser kleinen Geräte nicht unerhebliche Komplexität für die Einrichtung, Wartung und Sicherheitsüberprüfung hinzufügen (auf einigen dieser Geräte muss ich alles kompilieren, was ich zusammenstelle (von Quelle verwenden), und ich bin im Allgemeinen kein Fan meiner Geräte, die sich aktiv und ständig im Netzwerk bewerben.
Eine aktuelle manuelle Nicht-Lösung, die ich zumindest habe, um den known_hostsSchmerz zu mildern, besteht darin, ssh zur Verwendung /dev/nullals bekannte Hosts-Datei zu zwingen - was bedeutet, dass ich einfach aufgefordert werde, den Schlüssel jedes Mal zu überprüfen . Aber selbst mit meinem guten Gedächtnis und der ASCII-Schlüsselkunst, die hilft, skaliert das nicht und bricht die Automatisierung. Ich bin damit nur durchgekommen, weil die Anzahl der Tasten im Spiel für den Moment sehr klein ist.
Ich könnte Patches sshzulassen, um eine KeyOnlyOption für die strikte Überprüfung des Host-Schlüssels anstelle von "Ja" und "Nein" zuzulassen, aber ich weiß nur nicht, ob ich das jetzt in mir habe, vor allem, da dies bedeuten würde, dass ich es auch tun muss Es gelingt ihm, es im Upstream zusammenzuführen oder OpenSSH-Releases für noch mehr Geräte selbst zu erstellen.
Ich bin versucht, einen lokalen Dienst zu schreiben, der bekannte Host-Schlüssel nachverfolgt sshund einen benannten Unix-Domänensocket erstellt, der sshdann als bekannte Hosts-Datei anstelle der normalen Nur-Text-Datei verwendet werden kann. Dies scheint machbar zu sein, erfordert jedoch etwas Sorgfalt, um richtig und robust zu sein.
Offensichtlich ist das Deaktivieren der strengen Überprüfung der Host-Schlüssel keine Option. Wenn ich das tun würde, könnte ich genauso gut tun, als rshgäbe es keine Sicherheit mehr. Wir sind keine Tiere.
Ich hoffe also, dass es eine clevere Möglichkeit gibt, diese Anpassung des Verhaltens der Hostschlüsselüberprüfung durch OpenSSH vorzunehmen, um die IP-Adresse des Hostnamens zu ignorieren und nur den Schlüssel aus der Box zu checken.
Sie können ein einfaches Shellskript schreiben, das spontan eine benutzerdefinierte, vom Benutzer bekannte Hostdatei generiert, und bei Bedarf eine Verbindung zum Host herstellen.
Siehe ssh-Befehlszeile, um den Fingerabdruck des Serverhostschlüssels anzugeben .
Sie können bekannte Hosteinträge für jeden Hostschlüssel manuell ändern oder hinzufügen, wobei das Feld Name / IP auf gesetzt ist * .
Es stellt sich heraus, dass es zwei wenig bekannte Details zum bekannten Host-Dateiformat von OpenSSH gibt (dokumentiert aus irgendeinem Grund in der sshdHandbuchseite anstelle der sshHandbuchseite im Abschnitt SSH_KNOWN_HOSTS_FILE_FORMAT ), das genau das gewünschte Verhalten angibt :
OpenSSH erlaubt Platzhalterzeichen im Feld Hostname / IP, sodass mehrere (oder sogar alle) Hosts einem bestimmten öffentlichen Schlüssel entsprechen.
OpenSSH lässt mehr als einen bekannten Host-Eintrag für denselben Host zu und überprüft alle, sodass mehrere Host-Schlüssel für denselben Host als gültig betrachtet werden können.
Durch die Kombination dieser beiden Dinge können Sie eine beliebige Anzahl von Host-Schlüsseln hinzufügen, die für jeden Host, mit dem Sie eine Verbindung herstellen, als gültig betrachtet werden, während Sie gleichzeitig die strikte Überprüfung des Host-Schlüssels nutzen.
Dies funktioniert unabhängig davon, ob Sie HashKnownHostsein- oder ausgeschaltet haben oder nicht. Wenn Sie einen vorhandenen Hash-Eintrag ändern, ersetzen Sie immer noch das erste Feld (durch Leerzeichen getrennt) des Eintrags. Wenn Sie laufen ssh-keygen -HSie tun eine Warnung erhalten, die Wildcard - Einträge nicht gehasht werden kann, aber das ist in Ordnung: der ganze Sinn dieser Hashing versteckt, was bewirtet Sie bei verbinden den Inhalt der Datei freigelegt werden, sondern ein *Platzhalter in ähnlicher Weise nicht offenbaren bestimmte Hosts .
Ich habe mich in meiner Frage geirrt, zu sagen, dass es keinerlei Sicherheitsverlust gibt. Es gibt ein kleines, aber echtes zusätzliches Risiko: Wenn ein oder mehrere Host-Schlüssel für mehrere Hosts als gültig angesehen werden, können bei einem dieser Host-Schlüssel alle Ihre Verbindungen durch den gefährdeten Schlüssel mitM gekennzeichnet werden.
Für manche Menschen ist dies ein akzeptables Risiko, das die zusätzliche Bequemlichkeit in Bezug auf die üblichen Bequemlichkeiten vs.
Mit ein wenig zusätzlicher Einrichtung kann dies jedoch auf ein ziemlich schmerzloses Maß reduziert werden, indem für jeden "roaming" -Host eine bekannte Hosts-Datei erstellt wird, in der nur der mit einem Platzhalter versehene Hostschlüsseleintrag des Hosts gespeichert ist, eine Konfigurationsdatei für jeden, der dies angibt known hosts-Datei mit der UserKnownHostsDateioption und Angabe dieser Konfigurationsdatei mit der -FOption beim Verbinden.