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?
- 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.
- 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
Dokumentation
Links
Projekt
Weblinks