Ende 2014 wurde dank der Snowden-Leaks bekannt, dass auch das SSH-Protokoll zumindest teilweise geknackt werden konnte (siehe Spiegel-Artikel). Grund genug sich mit der OpenSSH-Konfiguration auseinanderzusetzen und die Installation soweit wie möglich abzusichern.

Die im Folgenden genannten Änderungen sollten für alle OpenSSH-Installationen gelten, auch wenn die Beispiele hier von einem Raspbian (SSH-Server) bzw. Windows  (SSH-CLient) stammen.

01| SSH-Clients für Windows

Bevor wir die Server-Konfiguration anpassen, sollten wir uns um den Client kümmern. Ansonsten kann es sein, dass nach der Server-Anpassung keine Verbindung mehr zum Server möglich ist.

Bei der Auswahl des Clients ist zu beachten, dass längst nicht jeder SSH-Client für Windows die momentan als sicher angesehenen Kryptoalgorithmen unterstützt, die später aktiviert werden sollen. Daher fallen die beliebten SSH-Clients der Windows-Welt Putty mindesten bis Developer Snapshot vom 10.04.2015, Kitty mindestens bis zur Version 0.64.0.1p und Bitvise SSH Client bis zur Version 6.24 raus.

Die einzigen freien SSH-Clients die ich für Windows finden konnte sind Tera Term Pro und der Cygwin OpenSSH Client. Ich habe mich für die Cygwin-Version entschieden. Vor allem weil hier auch gleich auch andere praktische Linux-Tools mitgeliefert werden und die Konfiguration des SSH-Clients problemlos auch auf Linux-Clients genutzt werden kann.

01.a| Client installieren

Die Installation der Cygwin-Umgebung ist denkbar einfach. Es muss lediglich die passende setup.exe von der Cygwin-Seite heruntergeladen und gestartet werden. Anschließend wie gewohnt den Anweisungen des Setup-Programms folgen und am besten einen Mirror in der Nähe auswählen. Bei der Paketauswahl findet man OpenSSH im Abschnitt “Net”.

Nachdem die Installation abgeschlossen ist, sollte ein Cygwin-Terminal gestartet und das Kommando “ssh-user-config” ausgeführt werden. Damit wird eine Initialkonfiguration für den SSH-Client und das Verzeichnis ~/.ssh angelegt. Damit sollte nun zumindest ein kompatibler Client in der Grundkonfiguration vorliegen, den wir für weitere Tests verwenden können.

02| Richtige Version des OpenSSH-Server installieren

Hinweis: Bevor Änderungen an der Server-Konfiguration vorgenommen werden, solltet ihr sicher sein, dass ihr per Konsole auf das System zugreifen könnt. Ist das nicht möglich so sollte vorübergehend eine andere Remote-Admin-Lösung aktiviert werden (z.B. Telnet oder VNC) damit man sich nicht selber aussperrt.

02.a| Bestimmen der OpenSSH-Version

Für eine  definierte Ausgangslage sollte zunächst das System auf den aktuellen Stand gebracht werden:

Danach ist zunächst die Version des installierten OpenSSH-Servers zu ermitteln:

Bei einer Version von 5.9 oder niedriger ist ein Update unbedingt zu empfehlen. Bei Debian Wheezy ist aber davon auszugehen, dass wie im Beispiel oben mindestens eine Version >= 6.0 installiert ist. Damit können schon zumindest halbwegs sichere Cipher-Suiten verwendet werden. Wer jedoch auch curve25519-sha256 verwenden will, der muss mindestens Version 6.4 installieren

02.b| OpenSSH >= 6.4  installieren (Optional)

Achtung: Die im Folgenden genannten Änderungen sorgen bei Raspbian für eine Vermischung der Pakete aus den Debian-Distributionen Wheezy und Jessie. Das kann dazu führen, dass beispielsweise durch das Ersetzen von Bibliotheken die Wheezy-Installation nicht mehr korrekt funktioniert! Die hier vorgeschlagenen Schritte haben für meine Installation zwar geklappt, können aber durchaus andere Installationen irreparabel beschädigen.

Daher hier bitte nur dann weitermachen, wenn man damit leben kann, dass die Raspbian/Debian-Installation anschließend nicht mehr funktioniert oder ein aktuelles Backup parat liegt.

Will man das Experiment mit der aktuellen OpenSSH-Version nicht wagen, so können dennoch einige Einstellungen in der /etc/ssh/sshd_config vorgenommen werden um zumindest das Beste aus der installierten Version herauszuholen. Beispielkonfigurationen hierzu finden sich für unterschiedliche OpenSSH-Versionen im GIT-Repository von BetterCrypto.

Damit Debian-Jessie-Pakete installiert werden können muss folgende Zeile in der Datei /etc/apt/sources.list eingefügt werden:

In der Datei /etc/apt/preferences wird dann festgelegt, welches Repository vorzugsweise verwendet werden soll. Dabei legt die Zeile Pin-Priority die Priorität fest. Ein Repository mit einer hohen Pin-Priority wird dabei bevorzugt verwendet.

Anschließend müssen nur noch die alten Pakete deinstalliert werden bevor das Paket aus dem Jessie Repository installiert werden kann. Der Parameter -t jessie gibt dabei an, dass die Pakete aus diesem Repository installiert werden sollen.

Bei der Installation muss ggf. wegen der neuen libc6 einige Services neu gestartet werden (z.B. cron). Hier sollte unbedingt kontrolliert werden, dass diese Dienste auch mit der neuen Version der Bibliothek wieder korrekt gestartet werden können.

Wenn alles richtig gelaufen ist, dann sollte jetzt eine OpenSSH-Version > 6.4 installiert sein:

03| SSHD-Konfiguration anpassen

Wenn eine passende Version installiert wurde, muss eigentlich nur noch die Server-Konfiguration angepasst werden.

03.a| Standard-Optionen

Zunächst sollten die grundlegenden Einstellungen in der sshd_config ergänzt oder abgeändert werden. Diese sollten eigentlich von allen SSH-Versionen unterstützt werden:

In den Zeilen 1-3 wird zunächst die Nutzung der alten Protokoll-Version 1 unterbunden. Gleichzeitig wird der DSA-HostKey deaktiviert, da diese Schlüssel immer nur 1024-Bit lang sind, was mittlerweile nicht mehr als sicher gelten. Demnach sollten nur noch RSA-Keys zugelassen werden. Einen neuen RSA-Key mit ausreichender Schlüssellänge wird später noch generiert.

Die Option in Zeile 3 deaktiviert das direkte Root-Login und durch den Eintrag in Zeile 5  werden die Teile des sshd, die mit root-Berechtigungen ausgeführt werden, minimiert.

Der Wert in Zeile 7 sorg dafür, dass SSH-Verbindungen nur dann zugelassen werden, wenn Owner und Permissions auf ssh-Dateien und Verzeichnisse korrekt gesetzt sind.

Damit die Dateien ~/.rhosts und ~/.shosts im User-Home bei der Authentisierung ignoriert werden ist der Eintrag aus Zeile 9 einzufügen und die Nutzung der Datei ~/.ssh/known_hosts bei der RhostsRSAAuthentication wird in Zeile 11 deaktiviert.

Zu guter letzt sollte die Nutzung leerer Passwöreter aus Sicherheitsgründen ebenfalls deaktiviert werden (Zeile 13).

03.b| Benutzer einschränken (optional)

Zusätzlich kann in der sshd_config festgelegt werden, welche Benutzer sich überhaupt per SSH mit dem System verbinden dürfen. Die Einschränkung dabei sowohl auf Basis der User-Namen als auch anhand von Gruppenzugehörigkeiten festgelegt werden. Da es einfacher zu Verwalten ist, sollte eine spezielle Gruppe für den SSH-Login durch folgenden Eintrag in der Datei /etc/ssh/sshd_config berechtigt werden:

Danach muss natürlich noch die Gruppe angelegt und die entsprechenden User hinzugefügt werden:

 03.c| Kryptoalgorithmen einschränken

Für eine sichere Verbindung sollten in der sshd_config die zugelassenen Kryptoalgorithmen eingeschränkt werden. Hier streiten sich die Geister was denn nun noch als sicher anzusehen ist und was nicht. In den folgenden Abschnitten werden vor allem die Algorithmen für den Schlüsselaustausch besonders eingeschränkt und für die symmetrische die Ciphern im CBC-Mode deaktiviert, sowie schwache MAC-Algorithmen eleminiert.

Welche Algorithmen im einzelnen von OpenSSH unterstützt werden, hängt von der verwendeten OpenSSH-Version ab. Wer also wagemutig die aktuelle Version von OpenSSH installiert hat, kann hier auf mehr Algorithmen zurückgreifen.

Für Versionen 6.0 – 6.4 sollten folgende Einträge vorgenommen werden:

Für Versionen > 6.4 sollten folgende Einträge vorgenommen werden:

03.d| Moduli anpassen

Da unter den oben aktivierten Key-Exchange-Algorithmen auch “diffie-hellman-group-exchange-sha256” zugelassen wird, muss noch sichergestellt werden, dass keine Moduli mit weniger als 2000 Bit verwendet werden. Dies wird mit folgenden Kommandos erreicht:

Alternativ können die Moduli mit ssh-keygen auch selbst erzeugt werden. Soll eine Moduli-Datei erzeugt werden, die in etwa der Datei entspricht, die mit der Distribution ausgeliefert wird, so müssen die Moduli für 2048, 3072, 4096, 6144 und 8192 Bit berechnet werden. Dabei ist allerdings zu berücksichtigen, dass das generieren der Modulis dann auf einem Intel I7 Prozessor mehrere Tage Rechenzeit und einige GB an Plattenplatz in Anspruch nehmen kann. Von einer Berechnung auf dem Raspberry sollte man daher eher Abstand nehmen.

Da die moduli-Datei bestandteil des SSH-Paketes ist, darf durchaus bezweifelt werden, ob die Neu-Generierung der Datei überhaupt einen Sicherheitsgewinn bringt. Denn wer die Moduli-Datei manipulieren kann, ist vermutlich auch in der Lage die Binaries im Paket zu ändern. In diesem Fall sind die Modulis das eher kleinere Problem.

Mit den oben genannte “ssh-keygen -G”-Kommandos werden dabei zunächst Primzahl-Kandidaten ermittelt, die mit den “ssh-keygen -T”-Kommando überprüft werden. Aus den verifizierten. Nachdem die einzelnen Moduli-Dateien generiert und getestet wurden, wird die endgültige Moduli-Datei erzeugt:

Diese moduli-Datei kann nun auf alle Systeme im Verzeichnis /etc/ssh abgelegt werden, auf denen sie benötigt wird.

03.e| Server-Schlüssel generieren

Wird eine OpenSSH Version >= 6.4 installiert, so sollte auch die Unterstützung für ed25519 aktiviert werden. Dazu muss folgender Eintrag in der sshd_config eingetragen werden:

Anschließend werden mit den folgenden Kommandos die alten Schlüssel gelöscht und neue Schlüssel für den SSH-Server generiert:

Damit der SSH-Server beim Systemstart automatisch gestartet wird, muss das Passwort für die Schlüssel leider leer bleiben (Parameter -N ”).

 03.f| Public Key Authentication aktivieren

Die Clients können sich bei SSH auf unterschiedliche Weise authentisieren. Leider ist dabei die Authentisierung per Passwort immer noch die Default-Option. Dazu wird in der Datei /etc/ssh/sshd_config mit der folgenden Option die Pbulic-Key-Authentication aktiviert:

Danach werden auf dem Client neue Schlüssel generiert:

Mit dem folgenden Kommando werden die Schlüssel auf den Server exportiert:

Dabei wird hoffentlich das letzte mal die unsichere Passwort-Methode zur Authenisierung verwendet. Wurde der Schlüssel erfolgreich auf den Server kopiert sollte jetzt auch schon ein Login mit dem neuen Schlüssel möglich sein:

Hat das alles geklappt, kann die Passwort-Authentisierung in der sshd_config deaktiviert werden, da diese grundsätzlich anfälliger ist für Brute-Force-Angriffe:

Da bis hierhin alle Änderungen an der /etc/ssh/sshd_config abgeschlossen sein sollte, ist jetzt ein guter Zeitpunkt zu überprüfen, ob die SSH-Konfiguration vom Server fehlerfrei eingelesen werden kann:

04| Client Konfiguration anpassen (optional)

Wer sich bis hierhin durchgearbeitet hat, hat nun einen relativ sicheren SSH-Daemon aufgesetzt. Sollen zusätzlich auch noch die Verbindungen zu SSH-Servern abgesichert werden, die nicht unter der eigenen Kontrolle stehen, so können an der ssh_config (nicht sshd_config) ebenfalls Konfigurationseinstellungen vorgenommen werden.

Achtung: Werden die hier vorgeschlagenen Einstellungen übernommen, so können ggf. keine Verbindungen mehr zu Server aufgebaut werden, die die aktuellen Algorithmen nicht unterstützen.

Mit der ersten Zeile werden nur noch in der Datei ~/.ssh/known_hosts keine Hosts mehr im Klartext gespeichert, sondern nur noch Hashes der Hostnamen, Dadurch kann ein Angreifer nicht mehr festellen, zu welchen Systemen vorher eine Verbindung aufgebaut wurde. Die restlihcen Parameter wollten sich von alleine erklären, wenn man die Server-Einstellungen erfolgreich umgesetzt hat.

Kann nach diesen Anpassungen eine Verbindung zu einem Server nicht mehr hergestellt werden, so können für einzelne Hosts auch weniger sichere Einstellungen und Algorithmen zugelassen werden (über den Parameter “Host xyz.domain.tld”).

05| Weiterführende Informationen

[1] Secure Secure Shell
[2] NSA-Proof SSH
[3] Entropux! OpenSSH moduli
[4] Consequences of tampered /etc/ssh/moduli