SSH/Hostkey - Beschreibung

Beschreibung

SSH Host Keys - nervig oder sinnvoll?

Bei der ersten 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?

Server identifizieren

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 beispielsweise: 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.

Anwendung

Problembehebung

Konfiguration

Dateien

Datei	Beschreibung

Anhang

Siehe auch

Dokumentation

Man-Page

prep(1)

Links

Projekt

Weblinks

TMP

ssh-Host-Keys erneuern

ssh-Server verfügen über einen Satz von Host-Keys, mit denen sich der Server gegenüber den Clients identifizieren kann.

Nach dem ersten erfolgreichen Verbindungsaufbau legt der ssh-Client den Host-Key des Servers in der Datei ~/.ssh/knownhosts ab.
Bei einem erneuten Verbindungsaufbau vergleicht der ssh-Client den vom ssh-Server aktuell übermittelten ssh-Host-Key mit dem zugehörigen gespeicherten ssh-Host-Key und gibt bei einem abweichenden Key - je nach Konfiguration des ssh-Clients - eine Warnung aus oder bricht sogar den Verbindungsaufbau ab.
Durch diese Prüfung können Man-in-the-Middle-Angriffe verbindet werden.

Damit dieser Mechanismus zuverlässig funktionieren kann, benötigt jeder ssh-Server einen eigenen Satz mit einmaligen ssh-Host-Keys.

Bei der Installation des Softwarepaketes mit dem ssh-Server wird üblicherweise ein neuer Satz mit einmaligen ssh-Host-Keys generiert.

Klont man hingegen einen bestehenden Server (beispielsweise

Aufsetzen eines neuen Servers aus einem Backup oder Disk-Images eines bestehenden Servers, Kopieren einer virtuellen Maschine), dann "erbt" der neue Server den Satz an ssh-Host-Keys.
Sofern der neue Server den bisherigen Server ersetzt, ist dies unproblematisch.
Sofern man einen neuen, zusätzlichen Server aufbaut, dann sollte dieser Server einen neuen Satz mit eigenen einmaligen ssh-Host-Key erhalten.

Keys ersetzen

Zum Erneuern der ssh-Host-Keys löscht man auf dem Server zunächst die bestehenden Host-Keys und generiert einen Satz neue Keys1):

cd /etc/ssh
sudo rm ssh_host_*
sudo ssh-keygen -A

Änderungen auf die Clients

Sofern für den ssh-Server bereits der alte ssh-Host-Key auf einem Client gespeichert ist, kann die ~/.ssh/knownhosts mit dem folgenden Befehl bereinigt werden:

ssh-keygen -R remote-server-name

Alternativ kann in der ~/.ssh/knownhosts der Eintrag auch mit einem Texteditor entfernt werden2).

Beim ssh-Client Blink (iOS) funktionieren die obigen beiden Lösungen nicht.

Hier ist der folgende Workaround notwendig:

In das Verzeichnis .ssh wechseln:

cd ~/.ssh

Inhalt der Datei known_hosts mit Zeilennummern anzeigen:

cat -n known_hosts

Entsprechende Zeile merken und mit sed löschen (im Beispiel Zeile 99):

sed -i.bak '99d' known_hosts

Quellen

cyberciti.biz: How To: Ubuntu / Debian Linux Regenerate OpenSSH Host Keys
serverfault: How to change a SSH host key?

1) In manchen Quellen wird für das Generieren der neuen Keys der Befehl dpkg-reconfigure openssh-server verwendet, der das Software-Paket für den OpenSSH-Server neu konfiguriert.

Es sollte jedoch ein ssh-keygen -A ausreichen, der den Satz ssh-Host-Keys um die fehlenden Typen ergänzt.Die erste Variante setzt voraus, dass ein OpenSSH-Server verwendet wird, während die zweite Variante allgemeingültig sein sollte.

2) Der ssh-Client gibt in den Warnungen die entsprechende Zeilennummer aus.