Netzwerksicherheit: Secure Shell

Einleitung

Die kryptographisch gesicherte Übertragung von Daten über ein potentiell unsicheres Netz wie das Internet wird für immer mehr Anwender relevant. Daraus ergibt sich ein wachsender Bedarf an standardisierten, hochwertigen und auf den unterschiedlichsten Systemen verfügbaren Sicherheitstechnologien und -werkzeugen. Zu den interessantesten diesbezüglichen Entwicklungen der letzten Zeit gehört die Secure Shell (SSH) des Finnen Tatu Ylönen.

Für UNIX existiert eine ziemlich ausgereifte, kostenfrei verfügbare SSH-Implementierung, von der eine etwas ältere Version auch nach OS/2 portiert wurde. Außerdem sind für die Zukunft kommerzielle Produkte auf der Basis der SSH angekündigt, u.a. ein Klient für Windows (3.1, 95, NT), der voraussichtlich noch in diesem Jahr die Produktreife erlangen wird.

Lauffähige SSH-Klienten und -Server sowie zugehörige Administrationswerkzeuge für die vom URZ unterstützten UNIX-Plattformen stehen auf /uni/global zur Verfügung.

Alle öffentlichen UNIX-Maschinen des Rechenzentrums sind bereits mit einem SSH-Server ausgestattet, so daß sie mittels Secure Shell genutzt werden können.
Die nachfolgenden Ausführungen beziehen sich daher primär auf diese Installation.

Im Interesse des Schutzes der privaten Daten empfiehlt es sich für Internet-Nutzer, künftig verstärkt auf solche Werkzeuge wie die SSH zurückzugreifen. Dabei ist nicht nur die Verwendung der Klienten gemeint, sondern ggf. auch die Installation eines Servers auf dem eigenen Rechner, um auf diesen von außen über eine gesicherte Verbindung zugreifen zu können.

Leistungsumfang

Die Secure Shell bietet einen vollständigen funktionalen Ersatz für die weit verbreiteten, aber mit ernsten Sicherheitsrisiken behafteten R-Utilities rlogin, rsh und rcp. Dafür stehen die beiden Kommandos ssh und scp zur Verfügung.

Der Klient ssh gestattet

In Anlehnung an die Namen der R-Utilities ist es auch möglich, dieses Kommando als slogin aufzurufen, wodurch sich weder die Funktionsweise noch die Optionen ändern.

Mit Hilfe von scp können Dateien wie bei rcp zwischen verschiedenen Rechnern über das Netz kopiert werden.

Im Gegensatz zu den R-Utilities und vielen Telnet- und FTP-Implementierungen realisiert die SSH auf der Basis anerkannter kryptographischer Verfahren eine zuverlässige gegenseitige Authentifizierung der Kommunikationspartner (Klienten und Server) sowie eine transparente Verschlüsselung des gesamten Datenstroms.
Daher sollten alle Administratoren die alten R-Utilities schnellstmöglich durch ihre SSH-Entsprechungen ersetzen.

Die transparent verschlüsselte Weiterleitung von X11- und TCP-Verbindungen ist eine besonders wertvolle Eigenschaft, da sie von keinem anderen im URZ verfügbaren Werkzeug angeboten wird. Damit läßt sich z.B. ohne großen Aufwand eine Absicherung von auf den Protokollen POP oder IMAP basierenden Mailboxzugriffen erreichen.

Neben der Secure Shell unterstützt das URZ auf mehreren Plattformen seit längerem lokal modifizierte Versionen von SRA-Telnet und -FTP, mit deren Hilfe bestimmten Sicherheitsrisiken effektiv begegnet wird. Für den Nutzer dieser Werkzeuge stellt sich unter Umständen die Frage nach den Vor- und Nachteilen der beiden Technologien, bei deren Beantwortung folgende Hinweise helfen sollen.

SRA erfordert keinerlei Administration, verursacht einen sehr geringen Overhead und ist optional, so daß auch herkömmliche Klienten (z.B. unter DOS) mit den SRA-fähigen Servern zusammenarbeiten können. Die kryptographische Sicherheit ist allerdings deutlich geringer als bei SSH. Außerdem bietet die Secure Shell einen größeren Funktionsumfang und ist durchgängig für alle UNIX-Plattformen des URZ verfügbar. Der Bedienkomfort von ftp ist in vielen Situationen höher als bei scp, deshalb empfiehlt sich mitunter eine Kombination beider Verfahren durch Weiterleitung von FTP-Verbindungen über SSH-Kanäle.

Kryptographische Verfahren

Die Secure Shell verschlüsselt den gesamten Datenstrom einer Sitzung unter Verwendung eines symmetrischen Verfahrens, wobei der hierfür benötigte Sitzungsschlüssel Ksess (Session Key) jeweils zufällig vom Klienten generiert wird. Die aktuelle Implementierung wählt vorzugsweise den auch beim PGP genutzten Algorithmus IDEA (International Data Encryption Algorithm) und unterstützt wahlweise u.a. DES und 3DES.

Die Verschlüsselung kann allerdings die Geheimhaltung der Daten vor unberechtigten Dritten nur dann gewährleisten, wenn der Klient sicherstellt, daß lediglich der echte Server in den Besitz von Ksess gelangt. Die sichere Schlüsselverteilung wird wie bei PGP durch die Anwendung des asymmetrischen RSA-Verfahrens erreicht, bei dem jeder Partner jeweils mindestens ein Paar aus öffentlichem und privatem Schlüssel (Public und Private Key) besitzt, das zur eindeutigen Identifizierung seines Eigentümers dienen kann.

Für jeden Serverrechner muß der Administrator (Super-User) deshalb mit Hilfe des Kommandos ssh-keygen ein langlebiges Paar RSA-Keys (Host-Keys) erzeugen und die beiden Schlüssel KHpubl und KHpriv in der ausschließlich ihm selbst zugänglichen Datei /etc/ssh_host_key ablegen. Der öffentliche Host-Key KHpubl wird in Textform in der für alle Nutzer lesbaren Datei /etc/ssh_host_key.pub bereitgestellt.

Eine RSA-Verschlüsselung unter Verwendung von KHpubl gestattet dem Klienten die notwendige sichere Übertragung des Sitzungsschlüssels. Nur der echte Server ist durch die Kenntnis des zu KHpubl gehörenden privaten Schlüssels KHpriv in der Lage, Ksess zu berechnen. Einem Angreifer gelingt dies nicht, so daß der verschlüsselte Dialog mit dem Klienten scheitert. Der Server weist dem Klienten demnach seine Identität indirekt dadurch nach, daß er diesen chiffrierten Dialog korrekt führen kann.

Um die Schlüsselverteilung zu vereinfachen, wurden die Host-Keys der öffentlichen Maschinen des URZ sowie vieler Rechner der Fakultät für Informatik bereits im File /uni/global/text/ssh_known_hosts hinterlegt und stehen beim Aufruf der SSH-Klienten auf diesen Maschinen automatisch zur Verfügung, da dort der Link /etc/ssh_known_hosts -> /uni/global/text/ssh_known_hosts existiert. Das URZ ist gern bereit, die Keys weiterer Maschinen aus den Fakultäten in diese Datei aufzunehmen.

Werden die öffentlichen Schlüssel zusätzlicher Rechner benötigt, so sind diese vom Nutzer in der privaten Datei $HOME/.ssh/known_hosts zu hinterlegen. Da laut SSH-Protokoll der Server seinen öffentlichen Host-Key zu Beginn einer Sitzung an den Klienten sendet, ist dieser auch in der Lage, die Datei automatisch um weitere öffentliche Schlüssel zu ergänzen, wenn er das erste Mal mit einem bisher unbekannten Server in Verbindung tritt. Dazu muß allerdings die Option StrictHostKeyChecking ausgeschaltet sein, was z.B. im URZ aus Sicherheitsgründen nicht der Fall ist.

Das automatische "Lernen" neuer Host-Keys ist potentiell problematisch. Gelingt es einem Angreifer durch eine geeignete Spoofing-Attacke, anstelle des Originalservers mit dem Klienten zu kommunizieren, so kann er sehr leicht den Sitzungsschlüssel in Erfahrung bringen. Er muß dem Klienten lediglich einen Key KHpubl präsentieren, dessen zugehörigen KHpriv er kennt. Diese Aufgabe ist trivial, da es genügt, ein RSA-Key-Paar zu generieren.

Entscheidet sich der Anwender für die etwas unsicherere, dafür aber deutlich bequemere automatische Pflege seines Files $HOME/.ssh/known_hosts, so muß er eine lokale Konfigurationsdatei $HOME/.ssh/config anlegen und die genannte Option StrictHostKeyChecking auf den Wert no setzen. Als Ausgangspunkt für die Erstellung der lokalen Datei empfiehlt sich das File /uni/global/etc/ssh_config.

Authentifizierung des Klienten

Dem Nutzer bzw. dem in seinem Auftrag arbeitenden Klienten stehen prinzipiell vier verschiedene Verfahren zur Verfügung, um sich gegenüber dem Server zu authentifizieren. Meist unterstützt der Server aber nur die folgenden drei Methoden (die vierte wird deshalb hier nicht näher betrachtet), die vom Klienten, sofern sie laut Konfiguration zulässig sind, in der angegebenen Reihenfolge bis zum ersten erfolgreichen Login oder bis zum definitiven Mißerfolg angewendet werden:
  1. Authentifizierung auf Basis der
  2. Authentifizierung auf der Basis nutzerbezogener RSA-Schlüssel sowie
  3. Authentifizierung durch das UNIX-Paßwort.

Die erste Methode gestattet allen Nutzern der R-Utilities einen relativ schnellen und einfachen Umstieg auf SSH unter Beibehaltung der gewohnten Umgebung. Die eventuell existierenden Dateien /etc/hosts.equiv bzw. $HOME/.rhosts werden von der Secure Shell unverändert verwendet. Es empfiehlt sich allerdings, die Datei $HOME/.rhosts in $HOME/.shosts umzubenennen, um Einbrüchen über die evtl. noch existierenden unsicheren R-Utilities vorzubeugen.

Im Unterschied zu den R-Utilities basiert der Nachweis der Identität des Klientenrechners bei dieser Methode nicht auf der relativ leicht fälschbaren IP-Absenderadresse, sondern auf langen, schwer zu brechenden RSA-Schlüsseln. Dieses Verfahren ist daher nicht anwendbar, solange der Administrator keine Host-Keys für den Klienten generiert hat.

Ein Server muß natürlich die öffentlichen Schlüssel des jeweiligen Partners kennen. Er verwendet mit den Dateien /etc/ssh_known_hosts und $HOME/.ssh/known_hosts dieselbe Datenbasis wie der Klient. Im Unterschied zum Klienten nimmt der Server generell keine Einträge in diese Files vor.

Bei der zweiten Authentifizierungsmethode verläßt sich der Nutzer nicht auf die RSA-Schlüssel der Rechner, sondern nur auf nutzerbezogene Schlüssel, die auf dem Server in der Datei $HOME/.ssh/authorized_keys zu hinterlegen sind. Diese höhere Sicherheit erfordert allerdings etwas mehr Administrationsaufwand, da die Schlüssel mit dem Werkzeug ssh-keygen vom Anwender erzeugt und über einen sicheren Weg verteilt werden müssen. Für weiterführende Informationen sei hier auf das Online-Manual bzw. die SSH-Page für /uni/global (http://www.tu-chemnitz.de/~hot/ssh/ssh.html) verwiesen.

Die dritte Methode erfordert seitens des Anwenders keine administrativen Vorkehrungen, da hier lediglich das UNIX-Paßwort benötigt wird. Die Übertragung des beim Login vom Nutzer eingegebenen Paßworts erfolgt selbstverständlich verschlüsselt.

Wichtige Dateien im Überblick

Die folgende Zusammenstellung gibt einen kurzen Überblick über die wichtigsten der auf den UNIX-Maschinen des URZ relevanten SSH-Dateien:

Datei Inhalt
/etc/ssh_host_key Host-Keys (KHpubl, KHpriv) eines Rechners
/etc/ssh_host_key.pub KHpubl im externen Format
/etc/sshd_config Konfigurationsinformationen für den Server
/etc/ssh_config systemweite Konfigurationsinformationen für den Klienten
/etc/ssh_known_hosts systemweite Liste bekannter öffentlicher Host-Keys; realisiert als Link zur Datei /uni/global/text/ssh_known_hosts
$HOME/.shosts Paare von Nutzern und Rechnern, denen das Login mit dem ersten Verfahren gestattet wird
$HOME/.ssh/known_hosts nutzereigene Liste bekannter öffentlicher Host-Keys
$HOME/.ssh/config nutzereigene Konfigurationsinformationen für den Klienten
$HOME/.ssh/authorized_keys Liste der für das zweite Authentifizierungsverfahren gültigen RSA-Keys

Anwendungsbeispiele

Die nachfolgenden Mitschnitte realer Login-Vorgänge sollen einen Eindruck von der praktischen Arbeit mit der Secure Shell vermitteln und somit den Einstieg in die Nutzung erleichtern.

Sofern außer der Installation der Server-Host-Keys keine weiteren Vorbereitungen getroffen wurden, kann lediglich das dritte Authentifizierungsverfahren genutzt werden, das die Eingabe eines Paßworts erfordert: 

hot@kirke 3 > ssh tantalus
Password: 

                  For copyrights see /etc/copyright.save

Terminal type ?(xterms): 
hot@tantalus-f 1 >
Um die Weiterleitung der X11-Verbindungen von auf dem Server gestarteten X11-Applikationen zum Klienten zu ermöglichen, stellt die Secure Shell die DISPLAY-Variable geeignet ein: 
hot@tantalus-f 1 > echo $DISPLAY
134.109.2.3:2.0
hot@tantalus-f 2 >
Die Nutzer sollten in ihrem eigenen Interesse darauf achten, diese Einstellung nicht nachträglich (z.B. durch die Startup-Scripts) wieder zu verändern, da sonst keine X11-Weiterleitung mehr möglich ist.

Wem die ständige Eingabe von Paßwörtern zu unbequem erscheint, sollte sich entweder des ersten oder des zweiten Verfahrens bedienen. Das folgende Beispiel zeigt ein Login von samson auf mmu unter Verwendung von Verfahren eins. 

hot@samson 11 > ssh mmu
Last login: Sat Mar 23 13:36:30 1996 from merkur.informatik

Terminal type ?(xterms): 
hot@mmu 1 >
Wie bereits dargestellt, ist eine hierfür notwendige Voraussetzung die Installation eines Host-Keys auf dem Klientenrechner durch dessen Administrator. Darüber hinaus ist ein entsprechender Eintrag in der Rhosts-Datenbasis erforderlich, der vom Nutzer selbst vorgenommen werden kann, z.B. in der Datei $HOME/.shosts: 
hot@mmu 1 > cat .shosts
samson.hrz.tu-chemnitz.de hot
hot@mmu 2 >
Die dargestellte Zeile besagt, daß dem Nutzer hot vom Rechner samson.hrz.tu-chemnitz.de aus ein Login auf dem lokalen Rechner (mmu) ohne Angabe eines Paßworts zu gestatten ist.

Sofern mindestens eine der Voraussetzungen für das erste Authentifizierungsverfahren nicht erfüllt ist, so versucht der SSH-Klient die Anwendung des zweiten Verfahrens. Hierfür ist es notwendig, daß der Nutzer eigene RSA-Keys generiert und geeignet im Filesystem des Servers abgelegt hat. Äußerlich ist im Normalbetrieb kein Unterschied zwischen den beiden Verfahren zu erkennen. Ein detailliertes Beispiel findet sich auf der SSH-Page für /uni/global.

Sofern keines der drei Verfahren zu einem erfolgreichen Login führt, empfiehlt sich der Aufruf des Klienten mit der Option -v: 

hot@kirke 9 > ssh -v tantalus
Dadurch werden die einzelnen Schritte des SSH-Protokolls ziemlich detailliert ausgegeben, so daß es meist relativ schnell möglich ist, die Ursache des Problems zu erkennen.

Geht es lediglich darum, ein Kommando auf der entfernten Maschine auszuführen, so kann dieses sofort auf der Kommandozeile spezifiziert werden. In diesem Falle wird keine interaktive Verbindung aufgebaut: 

hot@kirke 7 > ssh mmu.hrz ls -l /etc/dfs
total 4
-rw-r--r--   1 root     sys          232 Oct 10  1994 dfstab
-rw-r--r--   1 root     other         45 Oct 10  1994 fstypes
hot@kirke 8 >
Zum Kopieren aller Dateien *.html des Verzeichnisses ~/public_html der entfernten Maschine tantalus in das aktuelle Verzeichnis des lokalen Rechners kann folgendes Kommando dienen: 
hot@kirke 4 > scp hot@tantalus:~/public_html/\*.html .
hot@kirke 5 >
Das abschließende Beispiel zeigt den Schutz der Steuerverbindung von FTP durch die Weiterleitung über einen SSH-Kanal: 
hot@kirke 4 > ssh -L 2345:tantalus:21 tantalus
Dieses Kommando bewirkt neben dem bereits oben dargestellten Login auf tantalus die Einrichtung eines TCP-Servers auf dem hier als frei angenommenen Port 2345 des lokalen Rechners kirke. Sobald ein beliebiger Klient auf einem beliebigen Rechner eine TCP-Verbindung zu diesem Port aufbaut, sorgt die SSH für die Weiterleitung der Verbindung zum Port 21 (FTP-Port) des Rechners tantalus, so daß de facto eine Kommunikation mit dessen FTP-Server zustande kommt: 
hot@kirke 15 > ftp kirke 2345
Connected to kirke.informatik.tu-chemnitz.de.
220 tantalus-f FTP server (Version 4.162 Tue Nov 1 10:50:37 PST 1988) ready.
Name (kirke:hot): 
331 Password required for hot.
Password:
230 User hot logged in, no AFS authentication
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
Um die Übertragung von Klartext-Paßwörtern auf dem Netz zu vermeiden, sollte der FTP-Klient auf derselben Maschine gestartet werden, auf dem auch der SSH-Klient läuft. Von der Verwendung der Adresse localhost ist allerdings abzuraten, da dann in der Regel keine Datenverbindung vom Server zum Klienten aufgebaut werden kann.

Die im Beispiel gezeigte Kommandofolge bewirkt, daß der SSH-Klient im Vordergrund bleibt, so daß das ftp-Kommando in einem anderen Fenster eingegeben werden muß. Prinzipiell besteht die Möglichkeit, die Weiterleitung durch einen Klienten im Hintergrund zu realisieren. Dies erfordert aber einigen Zusatzaufwand.

Weiterführende Informationen

Die Secure Shell ist ein sehr leistungsfähiges Werkzeug mit einer Vielzahl von Optionen, die im Detail den Online-Manuals entnommen werden können. Daneben existieren verschiedene WWW-Seiten mit den unterschiedlichsten Informationen zum Thema SSH.

Auf folgende URLs soll hier stellvertretend hingewiesen werden:

Holger Trapp, 20. Mai 1996