Schluss mit TOFU bei SSH!

Viele von uns verlassen sich taeglich auf SSH (Secure Shell) zum Administrieren von Servern. Gerade als Linux Sysadmin hat man dabei mit einer Vielzahl von wechselnden Hosts zu tun, die alle ihren eigenen SSH-Hostkey benutzen. Daher sollte folgende Ausgabe ein bekanntes Bild sein:

Copy to Clipboard
Syntax HighlighterThe authenticity of host '192.168.128.2 (192.168.128.2)' can't be established.
ED25519 key fingerprint is SHA256:iXoSGQuDufdgTBub4pHBSJOKsJY1iQn4yzqKovapl10.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Das übliche Vorgehen hier ist, dass man den Fingerprint akzeptiert, wenn man sich das erste Mal mit diesem Host verbindet. Diese Warnung wird einfach als notwendiges Übel abgetan und ansonsten ignoriert – selbst wenn man versuchen wollte den Fingerprint zu überpruefen, liegt dieser meist nicht vor. Dieses Vorgehen wird auch als TrustOnFirstUse bezeichnet – kurz: TOFU.

Die SSH-Warnung sollte ernst genommen werden

Die Tatsache, dass SSH die Authentizität des Hosts nicht überprüfen kann, ist ein ernstes Problem. So kann beispielsweise eine MitM- oder Spoofing-Attacke nicht ausgeschlossen werden, bei der ein Angreifer sich zwischen Admin und Host geschaltet hat. Dies führt bei passwortbasierter Anmeldung zu einer Kompromittierung des Passwortes und damit des Hosts. Aber auch bei Public-Key Anmeldung kann das ein Problem darstellen: zwar wird hier der Zugriff selbst nicht kompromittiert, aber wenn z.B. vertrauliche Daten mittels Secure Shell übertragen werden kann ein Impostor so tun als wäre er der echte Host und einfach alle übertragenen Daten akzeptieren.

Ein Blick auf HTTPS

Was einem bewusst werden muss, ist dass die Fingerprint Meldung von Secure Shell den gleichen Stellenwert hat, wie ein selbstsigniertes SSL-Zertifikat. Hier warnt der Browser den Nutzer und lässt eine Verbindung erst zu, wenn man sich durch mehrere Schritte geklickt hat.

SSH kann Zertifikate

Analog zu SSL-Zertifikaten kann SSH ebenfalls Zertifikate verwenden. Und das sogar für Host und User. Das Beste dabei ist: es ist so einfach wie man es gewohnt ist.

Eine SSH-CA erstellen

Da alle SSH-Keypairs gleich sind, reicht es ein SSH-Keypair zu erzeugen:

Die Verwendung einer Passphrase sei hier dringend angeraten.

Den Hostkey signieren

Nun kopiert man sich den/die SSH Hostkeys auf den Signing host. Das Signieren eines Hostkeys geht dann wie folgt:

Der Parameter zu -I sollte die Adresse sein mit der man sich später an dem Host anmelden wird. Erzeugt wird dabei die Datei

ssh_host_ed25519_key-cert.pub

die man zurück auf den eigentlichen Host kopieren muss.

Den SSHd auf dem Host konfigurieren

Passend zum HostKey Eintrag in der sshd_config erstellt man nun folgenden Eintrag:

Copy to Clipboard
Syntax HighlighterHostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Dies weist den SSHd an, bei Bedarf das signierte Zertifikat vorzuzeigen. Läuft der SSHd bereits, muss der Service einmal neu gestartet werden, damit das Zertifikat verwendet wird.

Der CA auf dem Client vertrauen

Diesen Schritt muss man nur einmal pro CA durchführen, verwendet man also die gleiche CA für mehrere Hosts, reicht ein Eintrag. Folgende Zeile in die ~/.ssh/known_hosts eintragen:

Copy to Clipboard
Syntax Highlighter@cert-authority * ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGw/u6rZk9mv8GdG5BSnsYDTEjYDB45yzvED54PCUjF2 root@caserver01

Das * bedeutet, dass man diesem Zertifikat uneingeschränkt für alle Hostnames/IPs vertraut. Idealerweise sollte man das auf den Einsatzbereich der CA einschränken.

Fertig

Jetzt sollte keine Warnung mehr erscheinen und auch die known_hosts wird nicht mehr geflutet mit hunderten Fingerprints. Auch das Host Identity changed-Problem bei überlappenden IPs/Hostnames ist jetzt nicht mehr vorhanden.