© ellirra, 123RF.com

Eine zunehmende Zahl an Hosts und die Dynamisierung des Deployments machen eine sichere Host-Authentifizierung per SSH zur Herausforderung. Von mehreren Lösungsansätzen führt mitunter nur der älteste zum Ziel.

Bei seiner Einführung in den 90er Jahren war SSH schlicht die richtige Lösung zur richtigen Zeit, denn es schützt im Gegensatz zu Telnet, Rlogin und RSH die Authentifizierung und Datenübertragung kryptographisch. Beim Verschlüsseln setzt SSH auf eine Public-Key-Authentifizierung. Indem es den geheimen Schlüssel eines Nutzers oder Systems mit seinem öffentlichen Gegenstück abgleicht, prüft es die Identität des Schlüsselbesitzers zweifelsfrei.

Für die Benutzeranmeldung ist eine Public-Key-Authentifizierung zwar optional, empfiehlt sich aber gegenüber einer Passwortauthentifizierung, die bekanntlich nach einer Benutzerinteraktion verlangt. Das Public-Key-Verfahren gehört zu den seltenen Fällen, in denen zusätzliche Sicherheit mit einem Komfortgewinn einher geht: Dank des mitgelieferten »ssh-agent« darf der Nutzer nach einmaligem Entsperren des Schlüsselbunds beliebig viele sichere Verbindungen ohne Passwortabfrage aufbauen.

Host-basierte Authentifizierung

Für die Host-basierte Authentifizierung verlässt sich SSH nicht nur auf den Hostnamen, sondern kann auch mit Hilfe der Hostschlüssel den Quellhost autorisieren. Dabei autorisiert sich der Client mit dem Hostschlüssel des lokalen SSH-Servers und nicht mit einem gewöhnlichen Benutzerschlüssel [1].

Normalerweise lädt der SSH-Client einen SSH-Schlüssel aus dem Homeverzeichnis des Benutzers, beispielsweise »~/.ssh/id_dsa« , und autorisiert sich mit diesem beim Server. Bei der Host-basierten Authentifizierung verwendet der Client hingegen den privaten Schlüssel des SSH-Servers, der auf dem Clientrechner läuft. Der Zugriff erfolgt über das Tool »ssh-keysign« , das nur dafür existiert und mit Hilfe von SUID-Permissions die nur »root« zugänglichen Hostschlüssel in »/etc/ssh« benutzt. Der Zielserver muss anschließend den Hostschlüssel vom Client-Rechner über die Dateien »/etc/ssh/ssh_known_hosts« oder »~/.ssh/known_hosts« bestätigen.

Wie von Geisterhand

Die Authentifizierung per Schlüsselpaar klappt auch nicht-interaktiv, also ohne manuelle Eingriffe des Administrators. Das macht sie – zumindest in der Theorie – zur idealen Basis für eine automatisierte Kommunikation von Maschine zu Maschine (M2M). Nach bester Unix-Philosophie (“Ein Werkzeug pro Aufgabe”) verlassen sich dabei zahlreiche Tools auf die Infrastruktur von SSH. Kein Wunder also, dass die weit verbreitete SSH-Implementierung Open SSH dafür zahlreiche erweiterte Funktionen an Bord hat. Zu den bekannten Möglichkeiten zählen die Optionen, mit deren Hilfe SSH Daten tunnelt, Port- und X-Forwarding betreibt oder Daten verschlüsselt über SFTP und SCP überträgt. Doch es gibt auch eine Reihe weniger bekannter Optionen wie zum Beispiel »PermitRootLogin=forced-commands-only« , das nur eingeschränkte Root-Zugriffe erlaubt.

Vertrauensfrage

Aber wer oder was überprüft die Identität während der Verbindungsaufnahme und spricht damit das Vertrauen aus? In der Standardkonfiguration schaut SSH in den Dateien »/etc/ssh/ssh_known_hosts« und lokal unter »~/.ssh/known_hosts« nach, ob es den öffentlichen Schlüssel des Ziel-Hosts kennt. Ist das nicht der Fall, bittet SSH den Benutzer, den Fingerabdruck zu überprüfen (Abbildung 1). Vertraut er diesem, ergänzt SSH die »known_hosts« -Datei und baut weitere Verbindungen dann ohne erneute Nachfrage auf.

Abbildung 1: Beim ersten Anmelden auf einem fremden SSH-Host muss der Nutzer dessen Fingerabdruck bestätigen, was bei automatischen Installationen einen Nachteil darstellt.

Stimmt der tatsächliche nicht mit dem von SSH erwarteten Fingerabdruck überein – etwa wegen einer Neuinstallation des Servers – verweigert SSH den Verbindungsaufbau mit einem deutlichen Hinweis (Abbildung 2) und fordert vom Benutzer ein manuelles Eingreifen. Schon bei einer mittelgroßen Anzahl statischer Systeme stellt die gewissenhafte Überprüfung und Pflege der Fingerabdrücke eine Herausforderung dar.

Abbildung 2: Erscheint ein neuer Fingerprint unter einer bekannten IP-Adresse, wird SSH misstrauisch und fordert die Benutzer auf, die Datei mit den bekannten Hosts anzupassen.

In skalierbaren, virtualisierten Umgebungen, in denen täglich Dutzende virtueller Systeme hinzukommen oder bei eigenverantwortlich arbeitenden Entwicklerteams mit Shellzugang verschärft sich das Problem. Gerade solche Umgebungen nutzen massive M2M-Kommunikation, weil sie von der Automatisierung leben. Jede Benutzerinteraktion multipliziert sich dort schnell ins Hundert- oder gar Tausendfache.

Automatisierungstechnik, eine schwierige Disziplin

Eine sichere und automatisierte Authentifizierung für eine dynamische Umgebung zu gewährleisten, erweist sich in der Praxis als erstaunlich aufwändig. Das geschickte Kombinieren der SSH-Optionen »StrictHostkeyChecking=no« , »UserKnownHostsFile=/dev/null« sowie »GlobalKnownHostsFile=/dev/null« vermeidet zwar Rückfragen und Benutzereingriffe jeder Art. Der Administrator verliert jedoch zugleich jeglichen Schutz vor Spoofing- und Man-in-the-Middle-Angriffen, selbst die eingebaute Verschlüsselung wird dadurch wertlos. Im Ergebnis liegt die Sicherheit also kaum über der von Telnet.

Der von Open SSH vorgesehene Lösungsweg besteht darin, die Datei »/etc/ssh/ssh_known_hosts« zu verwenden. Die Manpage von SSH schreibt dazu: “Der Systemadministrator sollte diese Datei so pflegen, dass sie sämtliche öffentlichen Hostkeys aller Maschinen der Organisation enthält.”

Die Verteilung dieser einzelnen Datei lässt sich in kleineren, statischen Umgebungen noch recht leicht bewerkstelligen; geeignete Werkzeuge wie Cfengine, Puppet oder Chef sind in diesem Umfeld meist ohnehin vorhanden. Mit zunehmender Größe der Umgebung stößt das Konstrukt jedoch schnell an seine Grenzen – Änderungen müssten im Minutentakt auf hunderten oder gar tausenden Maschinen landen.

Lichtblick DNS

Die dritte Idee besteht darin, private Schlüssel zu verteilen. Sie wirft mehr Fragen auf als sie Antworten geben kann. Wo soll das System die zu verteilenden geheimen Schlüssel anfertigen und aufbewahren? Wie kann man dieses System schützen, wie die geheimen Schlüssel sicher verteilen? Nicht ohne Grund lautet die Regel, dass geheime Schlüssel das System niemals verlassen sollen.

Einen ersten Lichtblick stellt der 2006 standardisierte [2] SSHFP Resource Record im Domain Name System (DNS) dar, wobei SSHFP schlicht für SSH Fingerprint steht. Zum Prüfen des digitalen Fingerabdrucks, wie ihn Abbildung 1 zeigt, zieht das System einen DNS-Eintrag wie etwa

host.example.com.  SSHFP 2 1  123456789abcdef67890123456789abcdef67890

als Zusatzquelle heran und spart so eine Rückfrage beim initialen Verbindungsaufbau. Die »2« hinter SSHFP symbolisiert den verwendeten Algorithmus (hier: DSS), die »1« für den Typ des Fingerabdrucks (SHA-1). Ist kein passender Eintrag im DNS vorhanden, verhält sich SSH wie gewohnt.

Dieses Modell setzt voraus, dass im Rechenzentrum ein interner Nameserver existiert. Leider ist in der Praxis noch nicht vollständig klar, wie sich die Fingerprints automatisiert und sicher in das DNS eintragen lassen [3]. Schwerer wiegt aber, dass es ohne DNSSEC unmöglich ist, die Einträge abzufragen. Die wenigsten Rechenzentren dürften diese Voraussetzung für eine interne Namensauflösung bereits erfüllen.

Flucht ins Öffentliche

Den wohl fortschrittlichsten und sichersten Lösungsansatz verfolgt derzeit die zertifikatsbasierte Authentifizierung (siehe Kasten “Open-SSH-PKI”). Das Konzept der Public-Key-Infrastruktur (PKI) ist grundsätzlich von X.509 bekannt, Open SSH verwendet allerdings ein eigenes, recht minimalistisches Zertifikatsformat [4].

@cert-authority *.myorg.de,*.lan ssh-dss AAAAB3NzaC1kc3[...]@revoked * ssh-rsa AAAAB5W[...]

cert-authority,no-port-forwarding ssh-dss  AAAAB3NzaC1kc3[...]

Zusätzlich zu den privaten und öffentlichen Schlüsseln wird eine Certificate Authority (CA) eingeführt, die andere öffentliche Schlüssel mit dem eigenen beglaubigt. Vertraut ein Benutzer oder System nun einer CA, so überträgt sich dieses Vertrauen auf alle von ihr signierten Schlüssel. Der Verwaltungsaufwand beschränkt sich damit auf das Verteilen der CA-Schlüssel und das Signieren neuer Schlüssel.

Für neu aufgesetzte Systeme muss der Admin ohnehin diverse Sicherheits-Tokens (beispielsweise SSL-Zertifikate, Kerberos-Keytab und so weiter) initialisieren und kann in diesem Zuge auch die Open-SSH-Schlüssel signieren.

Da sowohl der CA-Schlüssel als auch die zu signierenden Schlüssel öffentlich sind, bestehen keine gesonderten Sicherheitsanforderungen für den Transport. Zu beachten ist für den Admin allerdings, mindestens Open SSH in Version 5.6 einzusetzen. Frühere Versionen von Open SSH verwenden ein anderes Zertifikatsformat und unterstützen keine Zertifikate für die Host-Authentifizierung.

Kerberos und RSH

Für Benutzer von Enterprise-Distributionen ist dies ein Spielverderber: Während Debian Wheezy und Ubuntu 12.04 die Anforderung erfüllen, paketieren sowohl SLES 11 SP2 als auch RHEL 6.4 sowie weitere davon abgeleitete Distributionen ältere Open-SSH-Versionen.

Bestehen beim Admin oder im Unternehmen Vorbehalte dagegen, neuere Versionen von Open SSH selbst zu paketieren, bietet sich RSH mit Kerberos als Alternative an, wenn zum Beispiel bereits eine Active-Directory-Umgebung mit Kerberos-Infrastruktur existiert. Gegenüber Open SSH mit Kerberos vermeidet es die »StrictHostkeyChecking« -Problematik, schützt aber dennoch vor Man-in-the-Middle-Angriffen. Zusätzliche Sicherheit bietet die Option »-x« zur (Teil)-Verschlüsselung der Verbindung [6].

Fazit

RSH als Lösungsvorschlag mag überraschen, ist jedoch Rahmenbedingungen, Rechenzentren und Enterprise-Linux-Versionen geschuldet. In Verbindung mit Kerberos spielt es zum jetzigen Zeitpunkt die einfache Host-Authentifizierung als Vorteil aus. Grundsätzlich sind die Zeiten von RSH aber gezählt – den Oldtimer ohne Kerberos einzusetzen, davon lässt sich nur abraten.

Für kleine, überwiegend statische, Umgebungen kann die Pflege von »/etc/ssh/ssh_known_hosts« eine akzeptable und weniger aufwändige Lösung sein. Sie skaliert eben nur schlecht. Es mag Zufall sein, dass die SSH-Manpage von nur einem Administrator in der Organisation spricht, es passt aber gut ins Bild.

Im direkten Vergleich zur Pflege der »/etc/ssh/ssh_known_hosts« ist die zertifikatsbasierte Authentifizierung von Open SSH kaum aufwändiger zu implementieren, aber ohne Komfort- und Sicherheitsverzicht hervorragend zu automatisieren. Gerade in großen und dynamisch virtualisierten Umgebungen kann sie daher punkten, so denn Open SSH in der richtigen Version vorliegt.