SSH Host Keys - nervig oder sinnvoll?

Bei der allerersten Verbindung zu einem Server per SSH bekommt man eine Meldung wie diese:

The authenticity of host ‚www.example.com (192.168.12.34)‘ can’t be established.
ECDSA key fingerprint is SHA256:86RDANuVFu5w3OF4RuFW04jqMfVbahR/sk4Yr/ElLI0.
Are you sure you want to continue connecting (yes/no)?

Die man dann nach dem klassischen Schema Ja/Nein/Weiss nicht/Hab Angst beantworten kann. Was genau ist der Sinn dieser SSH Host Keys und der oben gestellten Frage?

SSH Host Keys sind dafür da um den Host auf dem der SSH Server läuft eindeutig zu identifizieren.

Im Idealfall würde man beim ersten Verbindungsaufbau den Fingerprint des Host Keys überprüfen, also z.B.: mit dem Administrator des Servers den Fingerprint per Telefon vergleichen. Dadurch wäre dann sichergestellt dass man sich mit dem richtigen Server verbunden hat und man nicht von einem Angreifer auf eine andere Maschine umgeleitet wurde. Hat man den Key verglichen oder ist man sich zumindest sehr sicher dass man sich mit dem richtigen Server verbunden hat kann man oben stehende Frage mit "yes” beantworten. Der Key wird dann vom Client gespeichert und bei weiteren Verbindungen nur noch verglichen und nicht mehr gefragt.

Sollte im laufenden Betrieb dann doch mal eine Meldung wie die folgende kommen, gibt es Handlungsbedarf.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 a host key has just been changed.

Variante 1

Der Server wurde neu aufgesetzt (oder zumindest der SSH-Key neu generiert), in diesem Fall den Key aus der Datei ~/.ssh/known_hosts entfernen und wie bei einem erstmaligen Verbindungsaufbau verfahren.

Variante 2

Man hat sich auf einen Namen oder eine IP verbunden die nicht eindeutig einem Server zuzuordnen ist, und durch Cluster-Failover, Load Balancing oder ähnliches landet man jetzt auf einem anderen Server. Hier in Zukunft wenn möglich auf eindeutige Namen bzw. IPs verbinden.

Variante 3

Man ist gerade Opfer einer Man-in-the-middle Attacke geworden und ein Angreifer versucht den SSH-Verkehr auf einen anderen Server umzuleiten.

SSH Keys mögen zwar nervig erscheinen aber wenn man nicht selbst grob fahrlässig agiert können sie einen vor Angriffen auf die Verbindung bewahren.