Schluss mit TOFU bei SSH!

Viele von uns verlassen sich taeglich auf SSH 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

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

Die Warnung sollte ernst genommen werden

Die Tatsache, dass SSH die Authentizitaet des Hosts nicht ueberpruefen 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 fuehrt 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. vetrauliche Daten mittels SSH uebertragen werden kann ein Impostor so tun als waere er der echte Host und einfach alle uebertragenen Daten akzeptieren.

Ein Blick auf HTTPS

Was einem bewusst werden muss, ist dass die Fingerprint Meldung von SSH den gleichen Stellenwert hat, wie ein selbstsigniertes SSL-Zertifikat. Hier warnt der Browser den Nutzer und laesst 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 fuer Host und User. Das Beste dabei ist: es ist so einfach wie man es von SSH gewohnt ist.

Eine SSH-CA erstellen

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

Copy to Clipboard

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:

Copy to Clipboard

Der Parameter zu -I sollte die Addresse sein mit der man sich spaeter an dem Host anmelden wird. Erzeugt wird dabei die Datei

ssh_host_ed25519_key-cert.pub

die man zurueck 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

Dies weist den SSHd an, bei Bedarf das signierte Zertifikat vorzuzeigen. Laeuft 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 durchfuehren, verwendet man also die gleiche CA fuer mehrere Hosts, reicht ein Eintrag. Folgende Zeile in die ~/.ssh/known_hosts eintragen:

Copy to Clipboard

Das * bedeutet, dass man diesem Zertifikat uneingeschraenkt fuer alle Hostnames/IPs vertraut. Idealerweise sollte man das auf den Einsatzbereich der CA einschraenken.

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 ueberlappenden IPs/Hostnames ist jetzt nicht mehr vorhanden.