9.2.2. Sicheres Anmelden aus der Ferne: SSH

Das SSH-Protokoll (Secure SHell) wurde im Gegensatz zu telnet unter Beachtung von Sicherheit und Zuverlässigkeit entwickelt. Verbindungen unter Verwendung von SSH sind sicher: der Partner wird authentifiziert und aller Datenaustausch erfolgt verschlüsselt.

SSH bietet auch zwei Dateiübertragungsdienste an. scp ist ein Befehlszeilenprogramm, das wie cp benutzt werden kann, nur dass jedem Pfad zu einem anderen Rechner der Name dieses Rechners gefolgt von einem Doppelpunkt vorangestellt wird.

$ scp datei rechner:/tmp/

sftp ist ein interaktiver Befehl, ähnlich wie ftp. In einer einzigen Sitzung kann sftp mehrere Dateien übertragen, und es ist möglich, mit ihm Dateien auf einem entfernten Rechner zu bearbeiten (löschen, umbenennen, Berechtigungen ändern usw.).

Debian verwendet OpenSSH, eine freie Version von SSH, die vom OpenBSD-Projekt betreut wird (einem freien Betriebssystem, das auf dem BSD-Kernel aufbaut und seinen Schwerpunkt auf Sicherheit setzt), und eine Abspaltung der ursprünglich vom finnischen Unternehmen SSH Communications Security Corp. entwickelten SSH-Software. Dieses Unternehmen entwickelte SSH ursprünglich als freie Software, entschied sich jedoch schließlich, seine Entwicklung unter einer proprietären Lizenz fortzusetzen. Das OpenBSD-Projekt schuf daraufhin OpenSSH, um eine freie Version von SSH zu bewahren.

ZURÜCK ZU DEN GRUNDLAGEN Abspaltung

Eine „Abspaltung“ im Softwarebereich ist ein neues Vorhaben, das als Klon eines bestehenden Vorhabens beginnt und mit ihm konkurriert. Von da an entwickeln sich beide Programme, was neue Entwicklungen angeht, gewöhnlich schnell auseinander. Eine Abspaltung ist häufig die Folge von Meinungsverschiedenheiten innerhalb des Entwicklungsteams.

Die Option, ein Vorhaben abzuspalten, ist eine direkte Folge der Eigenart freier Software; eine Abspaltung ist ein heilsamer Vorgang, wenn sie die Fortführung eines Vorhabens als freie Software ermöglicht (zum Beispiel im Falle von Lizenzänderungen). Dagegen ist eine Abspaltung, die sich aus technischen oder persönlichen Meinungsverschiedenheiten ergibt, häufig eine Verschwendung menschlicher Ressourcen; eine andere Lösung wäre vorzuziehen. Auch der Zusammenschluss zweier Vorhaben, die früher durch eine Abspaltung gegangen sind, ist nicht gänzlich unbekannt.

Seit Etch ist OpenSSH in zwei Pakete aufgeteilt. Der Client-Teil befindet sich im Paket openssh-client und der Server-Teil im Paket openssh-server. Das Metapaket ssh ist von beiden Teilen abhängig und erleichtert die Installation beider (apt-get install ssh).

WEITERE SCHRITTE Hardwarebeschleunigung für SSH

Manche Hardware stellt von Haus aus Unterstützung für mathematische Funktionen zur Verfügung, die zur Verschlüsselung benutzt werden, wodurch die erforderlichen Berechnungen beschleunigt werden können und damit die Leistung einiger Hilfsprogramme erhöht (und die Belastung des Hauptprozessors verringert) wird. Zu diesen Hilfsprogrammen zählt insbesondere die OpenSSL-Bibliothek, die ihrerseits von OpenSSH verwendet wird.

Obwohl es ein Vorhaben zur Treiberstandardisierung (hauptsächlich auf Kernel-Ebene) gibt, wird die Vielfalt der Hardware noch immer ungleich und heterogen behandelt. So wird zum Beispiel das Padlock-System, das in Via-C3-Prozessoren enthalten ist, nur teilweise unterstützt. Obwohl der Linux-Kernel verschiedene Verschlüsselungsalgorithmen bietet, erlaubt die OpenSSL-0.9.8-Bibliothek in Squeeze nur die Weitergabe von AES-Verschlüsselungen an die dafür vorgesehene Hardware, nicht jedoch von SHA-Algorithmen; für Letzteres muss man die Bibliothek mit einem Patch neu kompilieren. http://www.logix.cz/michal/devel/padlock/

9.2.2.1. Schlüsselbasierte Authentifizierung

Jedes Mal, wenn sich jemand über SSH anmeldet, fragt der entfernte Server nach einem Passwort zur Authentifizierung des Benutzers. Dies kann problematisch sein, wenn man eine Verbindung automatisieren möchte, oder wenn man ein Hilfsprogramm verwendet, das häufige Verbindungen über SSH benötigt. Daher bietet SSH ein schlüsselbasiertes Authentifizierungssystem.

Der Benutzer erzeugt auf dem Client-Rechner mit dem Befehl ssh-keygen -t rsa ein neues Schlüsselpaar; der öffentliche Schlüssel wird in der Datei ~/.ssh/id_rsa.pub gespeichert und der dazugehörige private Schlüssel in ~/.ssh/id_rsa. Der Benutzer verwendet dann den Befehl ssh-copy-id server, um seinen öffentlichen Schlüssel auf dem Server zur Datei ~/.ssh/authorized_keys hinzuzufügen. Falls der private Schlüssel zur Zeit seiner Erzeugung nicht mit einer „Passphrase“ geschützt wurde, funktionieren alle nachfolgenden Anmeldungen auf dem Server ohne Eingabe eines Passworts. Anderenfalls muss der private Schlüssel jedes Mal erneut unter Eingabe der Passphrase entschlüsselt werden. Glücklicherweise ermöglicht es das Programm ssh-agent, private Schlüssel im Speicher zu halten, so dass das Passwort nicht ständig neu eingegeben werden muss. Hierzu verwendet man einfach (einmal pro Sitzung) den Befehl ssh-add, wobei Voraussetzung ist, dass die Sitzung bereits einer funktionsfähigen Instanz von ssh-agent zugeordnet ist. Debian aktiviert dieses Programm standardmäßig beim Start einer grafischen Sitzung, es kann jedoch durch eine Änderung der Datei /etc/X11/Xsession.options deaktiviert sein. In einer Konsolensitzung kann es manuell mit dem Befehl eval $(ssh-agent) gestartet werden.

SICHERHEIT Schutz des privaten Schlüssels

Wer immer im Besitz des privaten Schlüssels ist, kann sich auf dem entsprechend konfigurierten Konto anmelden. Daher ist der Zugriff auf den privaten Schlüssel durch eine „Passphrase“ geschützt. Selbst wenn jemand in den Besitz eines privaten Schlüssels gelangt (zum Beispiel die Datei ~/.ssh/id_rsa), muss er zusätzlich noch diese Phrase kennen, um ihn verwenden zu können. Dieser zusätzliche Schutz ist jedoch nicht unüberwindlich, und wenn Sie denken, dass die Sicherheit dieser Datei nicht mehr gewährleistet ist, sollten Sie diesen Schlüssel auf den Rechnern, auf denen er installiert wurde, deaktivieren (indem Sie ihn aus authorized_keys entfernen) und durch einen neu erzeugten Schlüssel ersetzen.

KULTUR OpenSSL-Schwachstelle in Debian Etch

Die OpenSSL-Bibliothek, die ursprünglich mit Debian Etch bereitgestellt wurde, hatte ein gravierendes Problem in ihrem Zufallszahlengenerator (RNG). Der zuständige Debian-Betreuer hatte eine Änderung vorgenommen, damit die Bibliothek bei Programmen, die sie verwendeten, keine Warnmeldungen hervorrief, die dann von Programmen zur Fehleranalyse wie zum Beispiel valgrind untersucht werden würden. Leider hatte diese Änderung auch zur Folge, dass der Zufallszahlengenerator nur eine Entropie-Quelle in Abhängigkeit von der Prozesskennung (PID) benutzte, deren 32.000 mögliche Werte keinen ausreichenden Grad an Zufälligkeit boten. http://www.debian.org/security/2008/dsa-1571

Insbesondere, wenn OpenSSL benutzt wurde, um einen Schlüssel zu erzeugen, wurde dieser immer aus einem Satz einiger hunderttausend Schlüssel erstellt (32.000 multipliziert mit einer kleinen Zahl von Schlüssellängen). Hiervon waren SSH-Schlüssel, SSL-Schlüssel und von zahlreichen Anwendungen, wie zum Beispiel OpenVPN, verwendete X.509-Zertifikate betroffen. Ein Eindringling brauchte nur alle Schlüssel auszuprobieren, um unberechtigten Zugriff zu erlangen. Um die Auswirkung des Problems einzuschränken, wurde der SSH-Daemon dahingehend verändert, dass er zweifelhafte Schlüssel, die in den Paketen openssh-blacklist und openssh-blacklist-extra aufgelistet sind, zurückweist. Darüber hinaus ermöglicht es der Befehl ssh-vulnkey, möglicherweise gefährdete Schlüssel im System zu identifizieren.

Eine eingehendere Analyse dieses Vorfalls zeigt, dass er die Folge mehrerer (kleiner) Probleme ist, sowohl beim OpenSSL-Projekt als auch beim Debian-Paketbetreuer. Eine weitverbreitete Bibliothek wie OpenSSL sollte - unverändert - keine Warnungen erzeugen, wenn sie von valgrind überprüft wird. Außerdem sollte der Code (vor allem so empfindliche Bereiche wie der Zufallszahlengenerator) besser kommentiert sein, um derartige Fehler zu vermeiden. Als der Debian-Betreuer sich seinerseits seine Änderungen von den OpenSSL-Entwicklern bestätigen lassen wollte, hat er seine Änderungen lediglich erläutert, aber nicht den entsprechenden Patch zur Überprüfung vorgelegt. Er hat sich auch nicht deutlich als Betreuer des entsprechenden Debian-Pakets ausgewiesen. Schließlich hat er die Änderungen, die er am ursprünglichen Code vorgenommen hatte, nicht deutlich dokumentiert; alle Änderungen wurden zwar in einem Subversion-Repository abgelegt, dabei aber beim Erstellen des Quellpakets zu einem einzigen Patch zusammengefasst.

Es ist unter diesen Umständen schwierig, Korrekturmaßnahmen zu finden, die solche Vorfälle in Zukunft verhindern. Die Lehre, die hieraus gezogen werden kann, ist, dass jede Abweichung, die Debian in Ursprungssoftware einführt, begründet, dokumentiert, möglichst dem Urspungsprojekt vorgelegt und breit veröffentlicht werden muss. Unter diesem Gesichtspunkt wurden das neue Quellpaket-Format („3.0 (quilt)“) und der Debian-Patch-Tracker entwickelt. http://patch-tracker.debian.org