Jeder Benutzer erstellt und zerstört mehr als 15 VMs pro Tag. Die VMs werden in der internen OpenStack-Cloud des Unternehmens erstellt.

Jedes Mal, wenn einem neuen VM eine IP-Adresse zugewiesen wird, die zuvor ausgegeben wurde, erhält der Benutzer den Fehler, dass die Überprüfung des gefürchteten Hostschlüssels fehlgeschlagen ist. Dies liegt daran, dass der SSH-Schlüssel nicht mit der IP-Adresse in der Benutzerdatei übereinstimmt known_hosts.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xxxxxxxxxxx
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Die zwei Lösungen, die ich sehen kann, sind:

• Deaktivieren Sie die strikte Überprüfung - (Sicherheitsrisiko)
• Lassen Sie die Benutzer ausführen ssh-keygen -RipAddress- (Benutzer haben diese Lösung satt, seitdem stoßen sie mehrmals täglich darauf)

Gibt es eine Möglichkeit, diese Fehlermeldung zu verhindern und dennoch sicher zu bleiben? Vielleicht die Sicherheitsüberprüfung nur für ein bestimmtes Subnetz deaktivieren?

Die großartige Funktion HostKeyAliaslöst Ihr Problem:

ssh -o HostKeyAlias=hostkeyalias__vm_2013-05-11_07 user@host

erstellt einen Eintrag hostkeyalias__vm_2013-05-11_07(ohne IP) in known_hosts. Natürlich können Sie ein Skript oder eine Shell-Funktion schreiben, die diesen Wert vor jedem SSH-Aufruf festlegt. Oder Sie verwenden eine Shell-Variable:

HOSTKEYALIAS=hostkeyalias__vm_2013-05-11_07
ssh -o HostKeyAlias=$HOSTKEYALIAS user@host

und ändern Sie, $HOSTKEYALIASwann immer die VM geändert wird. Von Zeit zu Zeit sollten die alten Einträge aus gelöscht werden known_hosts.

Erstellen Sie ~/.ssh/configmit den Inhalten:

Host *
    StrictHostKeyChecking no

Alternativ können Sie einen Alias ​​für ssh erstellen, um:

ssh -o StrictHostKeyChecking=no

Das Problem ist, dass ssheine 1: 1-Zuordnung zwischen IP-Adressen und Hosts vorausgesetzt wird. Wir müssen diese Zuordnung nur für die IP-Adressen Ihrer Cloud-Server aufheben.

Die Lösung

Fügen Sie Ihrer ~/.ssh/configDatei die folgende Zeilengruppe hinzu .

# Disable HostKey checking for servers which frequently change keys
Host 172.16.24.32  172.16.24.33  172.16.24.34
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Ändern Sie einfach die IP-Adressen und Sie sind fertig.¹

Optional: Eine Alternative für IP-Adressbereiche

Wenn Sie dies auf einen Netblock wie 192.168 / 16 anwenden möchten, können Sie Platzhalter wie folgt verwenden:

# Do not keep HostKeys for internal networks.
Host 10.*.*.*  192.168.*.*
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Optional: Verwenden von Hostnamen

In der ursprünglichen Frage wurden IP-Adressen erwähnt, aber Sie können natürlich auch Hostnamen verwenden. Zum Beispiel würde dies übereinstimmen ssh instance32.vm.yoyodyne.com:

Host *.vm.yoyodyne.com
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Wenn Sie sowohl Hostnamen als auch IP-Adressen verwenden möchten, müssen Sie beide explizit angeben, da SSH nicht mit der aufgelösten IP-Adresse übereinstimmt . Zum Beispiel, wenn Sie ssh ourvm.localals Verknüpfung haben für ssh 192.168.1.53:

Host 192.168.1.53  ourvm.local
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Vorbehalt

Seien Sie vorsichtig, wenn Sie sshdas Sicherheitsmodell umgehen . Stellen Sie insbesondere sicher, dass Ihre Platzhalter nicht mit echten Servern übereinstimmen, deren HostKeys sich nicht ändern.

¹ ^{Warum / dev / null? Ich werfe die KnownHosts-Daten in den Bit-Bucket, weil nur die Einstellung StrictHostChecking nodie Warnung entfernt, aber immer noch die Verbindung verweigert. Das ist albern, also gehe ich davon aus, dass OpenSSH das Verhalten irgendwann ändern oder eine neue Option hinzufügen wird. Wenn es eine bessere Lösung gibt, werde ich diese Antwort aktualisieren.}

Sie können den neuen Hostschlüssel von der VM-Konsole abrufen und die bekannte Hosts-Datei aktualisieren, nachdem eine Instanz gestartet wurde.