SSH/Hostkey

SSH/Hostkey - Identifikation eines SSH-Servers

Beschreibung

SSH-Host-Keys identifizieren einen SSH-Server eindeutig

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)?

Server identifizieren

Beim ersten Verbindungsaufbau Fingerprint des Host-Keys überprüfen

Fingerprint vergleichen

Sicherstellen, dass man mit dem richtigen Server verbunden ist

• und 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 die oben stehende Frage mit "yes" beantworten

• Der Key wird dann vom Client gespeichert und bei weiteren Verbindungen nur noch verglichen und nicht mehr gefragt.

Handlungsbedarf

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 eindeutigen 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.

SSH-Fingerprint prüfen

Prüfung der Authentizität eines SSH/Server

Wichtig, bei Erstverbindungen!

SSH-Verbindungen sind bei der ersten Verbindung am meisten verwundbar

Nachdem Sie zum ersten Mal eine Verbindung zu einem Server hergestellt haben, speichert der SSH-Client seinen Fingerabdruck

Wenn Sie sich zum ersten Mal mit einem Server verbinden war Ihr Client nicht in der Lage, seinen Fingerabdruck zu protokollieren und zu überprüfen, ob er korrekt ist

• Daher kann ein Angreifer erfolgreich einen Man-in-the-Middle-Angriff durchführen
• Die einzige Möglichkeit, um sicherzustellen, dass Sie sich von Anfang an mit dem richtigen Server verbinden, besteht darin, den Fingerabdruck Ihres SSH-Schlüssels manuell zu überprüfen

Wenn sich dieser Fingerabdruck ändert

• weil jemand versucht, Sie mit einem bösartigen Server zu verbinden,
• wird Ihr SSH-Client Sie warnen, dass sich der Fingerabdruck geändert hat

Fingerabdruck eines SSH-Schlüssels überprüfen

Bevor Sie Ihren Fingerabdruck überprüfen können, müssen Sie den dafür verwendeten Algorithmus kennen

Dieser sollte aus dem Inhalt Ihrer Nachricht hervorgehen

Die Authentizität des Hosts '172.86.75.163 (172.86.75.163)' kann nicht festgestellt werden. ED25519 key fingerprint is SHA256:NTw36MQjDxsHlxC/Xso5yKMlKJu93uYknRx2LEaqk7I. This key is not known by any other names. Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (ja/nein/[fingerprint])?

Sie können sehen, dass unser Schlüssel den Algorithmus ED25519 verwendet und mit SHA256 gehasht wird

• Sie sollten sich dies notieren, ebenso wie den Fingerabdruck selbst, in diesem Fall

NTw36MQjDxsHlxC/Xso5yKMlKJu93uYknRx2LEaqk7I

Ihr Schlüsselalgorithmus könnte auch ECDSA, RSA und DSA sein, und Ihr Hashing-Algorithmus könnte MD5 statt SHA sein

Überprüfen des Fingerabdrucks auf dem Server

Loggen Sie sich über eine vertrauenswürdige Methode in Ihren Server ein

Führen Sie den Befehl ssh-keygen aus, um den Fingerabdruck Ihres Schlüssels auszulesen

SHA256

ssh-keygen -lf [Datei]]

MD5

ssh-keygen -E md5 -lf [Datei]

Algorithmus	Datei
ED25519	/etc/ssh/ssh_host_ed25519_key.pub
ECDSA	/etc/ssh/ssh_host_ecdsa_key.pub
RSA	/etc/ssh/ssh_host_rsa_key.pub
DSA	/etc/ssh/ssh_host_dsa_key.pub

Beispiel

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
 256 SHA256:NTw36MQjDxsHlxC/Xso5yKMlKJu93uYknRx2LEaqk7I root@6311ad8b487e6f00018c5cd1 (ED25519)

Stellen Sie keine Verbindung zum Server her!
Wenn die Ausgabe nicht mit dem Fingerabdruck übereinstimmt, den Sie zuvor notiert haben

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.

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.

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

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 den 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

Konfiguration

Dateien

Datei	Beschreibung

Anhang

Siehe auch

---

• SSH/Hostkey/Signing
• SSH/Hostkey/TMP