Die Secure Shell SSH kann weit mehr, als ihr Name vermuten lässt: Ob verschlüsselte Tunnel zwischen mehreren Computern oder grafische Anwendungen via LAN – das Mehrzweckwerkzeug lässt kaum Wünsche offen.
Die wohl bekannteste Lösung, um Benutzern über das Netz einen Konsolenzugang auf entfernten Rechnern zu ermöglichen, stellt Telnet dar. So schön dieses Urgestein der Netzwerk-Kommunikation auch ist – es hat einen entscheidenden Nachteil: Alle Daten gehen im Klartext über die Leitung. Wirft ein Angreifer einen Sniffer an, bleibt das streng vertrauliche Admin-Passwort für den Server nicht lange geheim. Zugegeben, ganz so einfach geht es meist nicht, aber die Gefahr besteht. Und da alle gängigen Linux-Distributionen die Secure Shell (SSH) von Haus aus installieren, sollte diese Telnet wo immer möglich ersetzen.
Die Konfigurationsdateien finden von SSH sich in /etc/ssh. Hier gibt es eine Datei für den Server (sshd_config) und den Client (ssh_config). Diese Dateien enthalten eine Fülle von Optionen, für die Sie ausführliche Erläuterungen in den gleichnamigen Manpages finden. Große Anpassungen stehen für Anwender allerdings in der Regel nicht ins Haus. Bei den Default-Werten zeigt sich insbesondere Debian vorbildlich, und auch die anderen bekannten Distributionen stellen sinnvolle Vorgaben bereit.
Funktionsweise
Die Client-Server-Architektur von SSH basiert auf dem Gespann TCP/IP. Auf einem Rechner läuft der SSH-Server (sshd). Dieser lauscht standardmäßig auf TCP-Port 22 auf eingehende Verbindungen. Der Client seinerseits verbindet sich mit dem Server auf diesem Port.
Beim Verbindungsaufbau passiert im Hintergrund einiges: Zunächst verhandeln Server und Client, welche SSH-Protokollversion sie für die Kommunikation verwenden. Derzeit stehen die Protokolle SSH 1 und SSH 2 zur Verfügung, wobei SSH 2 deutlich sicherer ist. Daher kommt es seit einiger Zeit als Standard zum Einsatz. Details – auch zu der verwendeten Verschlüsselung – finden Sie im Kasten “SSH Protokolle”.
SSH Protokolle
Derzeit stellt die Secure Shell die Protokollversionen 1.3, 1.5 und 2 bereit. Gegenüber der Version 2 fallen die Möglichkeiten der Reihe 1 sehr beschränkt aus. Besonders das Angebot an Verschlüsselungsalgorithmen ist recht dürftig: Es kommen das unsichere DES oder das sichere, aber relativ langsame Triple-DES (3DES) zum Einsatz. Mit dem Blowfish-Algorithmus steht Ihnen auch hier eine schnelle und – jedenfalls bislang – sichere Verschlüsselungstechnik zur Verfügung. Version 2 bringt neben dem AES-Algorithmus noch weitere mit.
Weiterhin spricht gegen die Versionen aus der Serie 1, das Lücken im Protokoll theoretisch ein Knacken der Verschlüsselung ermöglichen. Hingegen arbeitet Version 2 deutlich langsamer, was sich beim Übertragen großer Datenmengen bemerkbar macht.
Beim Aushandeln des Schlüssels setzt Version 1 auf Client-seitig generierte Schlüssel, neudeutsch auch Keys genannt. Der Server sendet seinen öffentlichen Schlüssel an den Client. Der erzeugt eine zufällige, 256 Bit lange Zahl, verschlüsselt diese mit dem öffentlichen Schlüssel des Servers und sendet das Ergebnis an denselben.
Fortan läuft der Datenstrom mit dieser übermittelten Zufallszahl verschlüsselt ab. Schneidet ein Lauscher diese Kommunikation mit, befindet er sich im Besitz des (verschlüsselten) Keys. Mittels Ausprobieren aller Möglichkeiten – der sogenannten Brute-Force-Methode – gelingt es dann den Schlüssel zu ermitteln. Im Schnitt dauert dies allerdings mehrere Jahre.
Protokoll-Version 2 setzt ein Diffi-Hellman-Verfahren ein. Bei diesem Verfahren geht der eigentliche Schlüssel nie hin und her; Server und Client übertragen lediglich Daten, die es den Kommunikationspartnern ermöglichen, unabhängig voneinander den gleichen Schlüssel zu errechnen.
Einem Lauscher nützen diese Daten dagegen nichts, da ihm Werte zum Berechnen des Schlüssels fehlen. Dieses Verfahren zum Generieren des Schlüssels bietet deutlich mehr Sicherheit, weil keiner der beiden Kommunikationspartner den Schlüssel alleine bestimmt.
Zu den weiteren Verbesserungen gegenüber Version 1 gehört, dass die Software zum Prüfen der Integrität der Daten nicht mehr das betagte und unzuverlässigen CRC-Verfahren (Cyclic Redundancy Check) überlässt. Stattdessen verwendet Version 2 kryptologische Hash-Summen (Message-Authentication-Code-Verfahren). Auch das Multiplexing läuft nun besser. Dabei übertragen beide Seiten die Daten scheinbar gleichzeitige.
Alle Beispiele in diesem Artikel beziehen sich auf Protokoll-Version 2, auch wenn einiges mit Version 1 ebenfalls funktioniert.
Im nächsten Schritt handeln Server und Client den Algorithmus aus, gefolgt vom Schlüssel, den beide für diesen Datentransfer verwenden. Der Schlüssel gilt einmalig für diese Kommunikation und beide Seiten vernichten ihn nach Verbindungsende. Für längere Verbindungen ändert sich der Schlüssel zusätzlich in regelmäßigen Abständen, standardmäßig stündlich.
Ein erstes Login
Am einfachsten melden Sie sich mit der klassischen Benutzername/Passwort-Methode an. Dabei verwendet der SSH-Client automatisch Ihren Benutzername als Anmeldename auf dem entfernten Rechner. Beim ersten Login kennt der Client den Host-Key des Servers noch nicht und verlangt daher eine Bestätigung, dass Sie sich wirklich mit diesem Rechner verbinden wollen. Erst nach einer positiven Antwort importiert das Programm den so genannten Fingerprint (Fingerabdruck, Abbildung 1).
Abbildung 1: Beim ersten Login importiert SSH den Host-Key des entfernten Rechners.
Dies ist ein guter Moment, den Administrator des entfernten Rechners zu kontaktieren und den Key-Fingerprint abzugleichen. So verhindern Sie sogenannte Man-in-the-Middle-Attacken. Bei diesen leitet ein Angreifer Ihren Netzwerkverkehr auf seinen Rechner um und täuscht Ihnen ein entsprechendes Login vor.
Bestätigen Sie in einem solchen Fall unbedacht und geben Ihr Passwort ein, befindet sich der Angreifer im Besitz Ihres (verschlüsselten) Passworts. Aus diesem Grund ist hier Vorsicht angebracht. Ändert sich der Host-Key, dann verweigert der Client bei einem späteren Login die Verbindungsaufnahme. Abbildung 2 zeigt die entsprechende Ausgabe des SSH-Clients.
Abbildung 2: Ändert sich der Host-Key, verweigert Ihnen der SSH-Client den Zugang.
Hier hilft nur, den betreffenden Fingerprint aus $HOME/.ssh./known_hosts zu löschen und nach Rücksprache mit dem betreffenden Admin den neuen Key zu akzeptieren. Sie konfigurieren dieses Verhalten über die Variable StrictHostKeyChecking in ssh_config.
Möchten Sie sich auf dem entfernten Rechner nicht unter Ihrem derzeitigen Benutzernamen, sondern als ein anderer Benutzer anmelden, verwenden Sie die Option -l Login-Name. So meldet Sie etwa die Zeile ssh -l tuppes sector als Benutzer tuppes auf dem Remote-Rechner an. Alternativ akzeptiert SSH auch die folgende Syntax: ssh tuppes@sector. Um lediglich einen einzelnen Befehl auf dem anderen Rechner auszuführen, hängen Sie diesen einfach hinten an (Listing 1).
Listing 1
jha@scotti:~$ ssh sector "ls -l" Password: insgesamt 52 drwxr-xr-x 3 tuppes users 4096 2005-08-26 12:38 . drwxr-xr-x 16 root root 4096 2005-09-07 13:47 .. -rw-rw-r-- 1 tuppes users 266 2005-04-12 12:00 .alias
Falls es Ihnen lästig fällt, stets Ihr Passwort einzugeben, können Sie auf Public-Key-Authentication zurückgreifen. Hier kommen Verschlüsselungsverfahren zum Einsatz, wie sie auch von GnuPG bekannt sind. Um diese Methode zu verwenden, generieren Sie mit ssh-keygen als erstes ein Schlüsselpaar: ssh-keygen -b 1024 -t rsa. Die Software meldet daraufhin, dass sie einen Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel nach dem RSA-Verfahren erzeugt hat. Die Abfrage nach dem Passwort bestätigen Sie zweimal mit [Enter]. Anschließend signalisiert das Programm, in welchen Dateien es die Daten ablegt, und zeigt dann den Fingerprint des neuen Schlüssels an.
In diesem Beispiel generiert die Software ein RSA-Schlüsselpaar (Option -t rsa) von 1024 Bit Länge (Option -b 1024) generiert. Einen RSA-Key eignet sich für den Einsatz mit beiden Protokollversionen. Die Key-Länge sollte aus Sicherheitsgründen 1024 Bit nicht unterschreiten. Wollen Sie auf Nummer sicher gehen, verwenden Sie einen Schlüssel mit 2048 Bit Länge. Der gilt nach derzeitigem Wissensstand bis etwa zum Jahr 2020 als sicher. Die Key-Länge hat übrigens keinen Einfluss auf die Geschwindigkeit des Datentransfers, da das Programm die Daten ja nicht mit diesem Key verschlüsselt.
Im nächsten Schritt kopieren Sie den öffentlichen Schlüssel auf den Zielrechner in die Datei $HOME/.ssh/authorized_keys, beispielsweise via Diskette:
mount /media/floppy cat /media/floppy/id.rsa.pub >> $HOME/.ssh/authorized_keys umount /media/floppy
Keinesfalls sollten Sie den Key mit einem unsicheren Verfahren wie übertragen, etwa per E-Mail oder via FTP. Das unspektakuläre Login mit dem neuen Schlüssel zeigt Abbildung 3.
Abbildung 3: Mit Public-Key-Authentifizierung verläuft der Login komfortabler, da ohne Passwort-Abfrage.
Schlüssel für interaktive Sitzungen sollten Sie mit einem Passwort versehen. Ansonsten ermöglichen Sie jedem mit einem physikalischen Zugang zu Ihrem Rechner, sich unter Ihrem Namen am entfernten Rechner anzumelden. Das passwortfreie Login mittels Schlüssel kommt häufig bei automatisiertem Kopieren von Dateien auf einen Remote-Rechner zum Einsatz.
Wenn Sie beispielsweise jeden Abend ein Backup fahren, dass Sie automatisch auf einen anderen Rechner kopieren möchten, eignen sich Keys ohne Passwort bestens. Wäre der Schlüssel mit einem Passwort versehen, müssten Sie dieses bei jedem Kopiervorgang eingeben – von automatisch keine Spur mehr.
Dreingabe
Mit dem SSH-Paket kommen noch zwei weitere interessante Programme auf den Rechner – Secure Copy (Scp) und Secure FTP (Sftp). Wie die Namen schon vermuten lassen, handelt es sich um Programme zum Kopieren und für FTP-Transfers über SSH. Die grundlegende Syntax der beiden Programme ähnelt sich stark.
Um beispielsweise die Datei test.txt aus Ihrem Home-Verzeichnis auf einem entfernten Rechner in das aktuelle Verzeichnis zu kopieren, verwenden Sie die folgende Kommandozeile:
scp RemoteRechner:test.txt .
Je nach Authentifizierungsmethode geben Sie eventuell noch Ihr Passwort ein. Zwingend ist in jedem Fall den Doppelpunkt: Er trennt den Namen des entfernten Rechners vom Pfad. Ebenso obligatorisch ist die Angabe des lokalen Pfades. Im einfachsten Fall handelt es sich um den aktuellen Ordner, den im Beispiel der abschließende Punkt repräsentiert. Um mehrere Dateien zu kopieren, schreiben Sie diese getrennt durch Leerzeichen hintereinander:
scp Remote-Rechner A:test1.txt Remote-Rechner B:test2.txt .
Arbeiten Sie hier mit einem Standard-Login via Passwort, verlangt der Client für jede zu kopierende Datei die Eingabe des Passworts. Verwenden Sie hingegen die oben vorgestellte Methode mit einem Schlüssel ohne Passwort, entfällt die Eingabe. Mit dem Befehl scp Remote-Rechner A:test.txt Remote-Rechner B: kopieren Sie die Datei von Rechner A zu Rechner B.
Um die Datei als Benutzer tuppes (und damit aus /home/tuppes) in das lokale Verzeichnis zu kopieren, gehen Sie folgendermaßen vor:
scp tuppes@RemoteRechner:test.txt .
Im Unterschied zu SSH kommt hier nicht die Option -l Username zum Einsatz. Kopieren Sie andersherum – von lokal nach remote – gestaltet sich das genau so einfach:
scp ./test.txt tuppes@RemoteRechner:
Der Befehl kopiert die Datei tuppes.txt aus dem aktuellen Verzeichnis (./) nach /home/tuppes auf dem entfernten Rechner. Achten Sie auch hier wieder auf den abschließenden Doppelpunkt.
Sftp nutzt den gleichen Befehlsaufbau wie SCP, kennt aber zwei Betriebsmodi: einen interaktiven Modus, wie vom normalen FTP gewohnt, sowie einen Batch-Modus. Um unsere Beispieldatei im Batch-Modus via Sftp vom Remote-Rechner zu holen, geben Sie folgendes ein:
sftp RemoteRechner:test.txt .
Tippen Sie sftp RemoteRechner:test.txt remote_test.txt, dann benennt das Programm die Datei zusätzlich lokal in remote_test.txt um. Ein einfaches sftp RemoteRechner öffnet eine interaktive verschlüsselte FTP-Session auf dem entfernten Computer, wo der Server nach erfolgreichem Anmelden FTP-Befehle wie GET oder PUT akzeptiert.
Tunnelbau
Das beste zum Schluss: SSH erlaubt es Ihnen, beliebige Protokolle in SSH zu verpacken. Beispielsweise bietet es die Möglichkeit, das oben erwähnte Telnet-Protokoll über eine verschlüsselte SSH-Verbindung zu leiten – unbemerkt vom Anwender. Der Fachausdruck für das Verpacken eines Protokolls in einem anderen heißt allgemein Tunneln.
Ein SSH-Tunnel arbeitet nach einem einfachen Prinzip. Wie jeder andere Dienst lauscht er auf einem Port und wartet auf Verbindungen. Geht eine Verbindung ein, verschlüsselt der Tunnel die Daten und gibt sie an die TCP/IP-Schicht weiter, die die Daten an den Remote Rechner sendet. Dort wandern die Daten den umgekehrten Weg hoch zur Anwendung. Abbildung 4 verdeutlicht den Vorgang.
Abbildung 4: Vereinfachtes Schaubild des Paketflusses durch einen SSH-Tunnel.
Gemäß Vorgabe dürfen nur Programme den Tunnel nutzen, die auf demselben Rechner laufen. Möchten Sie auch anderen Rechnern im Netzwerk den Tunnel zur Verfügung stellen, geben Sie beim Aufbau des Tunnels dem Kommando ein -o GatewayPorts=yes mit auf den Weg. Die zusätzliche Option bewirkt, dass der Tunnel nun allen Rechnern im Netzwerk offen steht. Alternativ setzen Sie die Option in der Konfigurationsdatei ssh_config.
Der Vorgang ähnelt einer VPN-Verbindung (Virtual Private Network), die ebenfalls verschlüsselt ist. Der große Vorteil von SSH gegenüber VPN (beispielsweise mit OpenSWAN) liegt in der Einfachheit: Ein VPN aufzusetzen erfordert eine gehörige Portion an Kenntnis und oft auch an Geduld. Die SSH-Variante hat allerdings den Nachteil, dass Sie immer nur einen einzelnen TCP-Port weiterleitet. Anders gesagt: Sie brachen genau so viele SSH-Tunnel, wie Sie Ports weiterleiten wollen. Wollen Sie die komplette Kommunikation zwischen zwei Rechnern verschlüsseln, sind Sie mit einem VPN vermutlich besser bedient.
Grundlegend darf jeder Benutzer Tunnels aufbauen, aber Tunnels mit privilegierten Ports – darunter fallen alle mit einer Nummer unter 1024 – sind dem Administrator root vorbehalten.
Um einen Tunnel vom lokalen Rechner zu einem entfernten Rechner aufzubauen, der das Telnet-Protokoll (Port 23) tunnelt, geben Sie ein:
ssh -c blowfish -L 23:Remote-Box:23 Remote-Box
Das Kommando baut über die -L Option einen Tunnel vom lokalen Port 23 (die erste “23”) zum einem entfernten Rechner auf Port 23 auf. Dabei löst die die schnellere Blowfish-Verschlüsselungsmethode das langsamere 3DES-Verfahren ab. Indem Sie den Namen des entfernten Rechners zweimal angeben, nutzen ein weiteres Feature von SSH: So bauen Sie einen Tunnel auf, der vom ersten Rechner über einen zweiten zu einem dritten Computer führt.
Das Kommando ssh -L 23:192.168.1.1:23 192.168.20.5 startet anschließend den Tunnel auf dem lokalen Rechner und führt ihn über eine Zwischenstation (192.168.1.1) zum eigentlichen Endpunkt (192.168.20.5). Die allgemeine Syntax zum Aufbau eines Tunnels von lokal zu entfernt lautet also: ssh -L LokalerPort:Remote-Rechner 1:Remote-PortRemote-Rechner_2. Bei einem direkten Tunnel entsprechen sich die beiden Rechnerangaben.
Abbildung 5 zeigt mittels Netstat, dass tatsächlich eine Telnet-Verbindung unter Zuhilfenahme von SSH besteht. Der erste Netstat-Befehl verrät, dass ein SSH-Prozess mit der Prozess-ID 3311 auf Port 23 lauscht. Der zweite Befehl zeigt eine bestehende Verbindung auf Port 22 mit genau dieser PID 3311. Konsequenterweise läuft die Telnet-Kommunikation durch die SSH-Connection, also in SSH getunnelt.
Abbildung 5: Das Programm Netstat zeigt einen bestehende Tunnel via SSH.
Die Syntax zum Aufbau eines Tunnels legt nahe, dass lokaler und entfernter Port nicht identisch zu sein brauchen. Genau das ist der Fall. Angenommen, auf dem Remote-Rechner läuft ein Proxy auf Port 3128 und der Proxy ist für transparentes Proxying konfiguriert, so leiten Sie alle HTTP Anfragen transparent so um:
ssh -o GatewayPorts=yes -L 80:RemoteRechner:3128 RemoteRechner
Ein solches Umlenken eines Ports auf einen anderen heißt Port-Forwarding. Diese Methode erfordert wieder den Einsatz des Parameters -o GatewayPorts=yes, damit anderen Rechnern im Netzwerk der Tunnel offen steht.
Das Tunneln funktioniert auch in die umgekehrte Richtung. Mit der folgenden Syntax bauen Sie einen Tunnel von einem entfernten Rechner zu dem lokalen Computer auf:
ssh -R Remote-Port:LokalerRechner:LokalerPort RemoteRechner
Im Falls des Proxys ergibt sich daraus:
ssh -o GatewayPorts=yes -R 3128:LokalerRechner:80 RemoteRechner<C>.
Grafische Anwendungen tunneln
Bekanntermaßen ist das X-Window-System von Haus aus netzwerkfähig. Nur nutzt kaum jemand diese Fähigkeit aus Sicherheitsgründen aus, denn auch hier läuft die Kommunikation unverschlüsselt übers Netz. Getunnelt in SSH, sieht die Sache hingegen recht attraktiv aus.
Um X11 zu tunneln, emuliert der SSH-Daemon sshd einen X-Server und besetzt ein Display, standardmäßig die Nummer 11. Wenn Sie sich auf dem Server einloggen, setzt dieser die Umgebungsvariable DISPLAY auf diesen Wert, genauer gesagt auf localhost:11.0. Der Sinn liegt darin, Kollisionen mit dem lokal laufenden X-Server zu vermeiden. Alle Daten, die ein Rechner an dieses Display sendet, wandern verschlüsselt zu Ihrem Rechner.
Viele Distributoren deaktivieren standardmäßig das X11-Forwarding – so der Fachausdruck für das getunnelte Weiterleiten von X11-Anwendungen. Sie aktivieren es wie folgt: Setzen Sie dazu auf dem Rechner, der forwarden soll, in sshd_config die Variable X11Forwarding auf yes. Die Variable X11DisplayOffset mit dem Standardwert 10 bestimmt den Abstand Ihres virtuellen Displays zum realen Display. Diese verändern Sie nicht.
Als nächstes setzen Sie auf dem Rechner, der das getunnelte X11 anzeigt, in der Datei ssh_config die Variable ForwardX11 auf yes. Damit sind die Konfigurationsarbeiten bereits erledigt.
Abbildung 6: Eine geforwardete X11-Verbindung – Xclock kommt vom Remote Rechner.
Zuerst loggen Sie sich auf dem entfernten Rechner ein und rufen dann zum Beispiel das Programm Xclock auf. Abbildung 6 zeigt auch das Display (localhost:11.0), sowie den dazugehörigen Prozess und die Netzwerkverbindungen.
Fazit
Das SSH-Paket beinhaltet eine Sammlung wichtiger Programme, die die Arbeit über das Netz deutlich sicherer gestalten. Der Funktionsumfang von einfachen verschlüsselten Verbindungen über Tunneling und Port-Forwarding bis X11-Forwarding deckt für den täglichen Gebrauch alle Wünsche ab.
