Die klassischen Unix-Programme Telnet und FTP erlauben Verbindungen und Datei-Transfers zu anderen Rechnern im Netz, sind aber unsicher: Alle Daten werden unverschlüsselt übertragen. Deswegen verwenden man heute die SSH-Tools (Secure Shell), die das Gleiche ermöglichen, dabei aber durch Verschlüsselung für Sicherheit sorgen.

SSH (Secure SHell) steht sowohl für den Namen des Protokolls als auch für die Implementierung, das Programm selbst. Hier kommt eine sichere Methode, sich auf anderen Computern über eine verschlüsselte Verbindung einzuloggen, Kommandos (auch X-Anwendungen) auf dem entfernten Rechner auszuführen und Daten zwischen Computern zu kopieren. SSH ermöglicht eine weit sicherere Kommunikation als unverschlüsselte Protokolle, wie z. B. telnet oder ftp, bei denen die Daten und damit auch die Passwörter unverschlüsselt durch das Netz wandern. Die Programme ssh und scp ersetzen damit vollständig die Tools rlogin, rsh und rcp.

Im Moment existieren zwei unterschiedliche und nicht kompatible Versionen des SSH-Protokolls – SSH 1.X und SSH 2.X. Version 1.0 wurde 1995 vom Finnen Tatu Ylönen freigegeben und setzte sich schnell als Standard durch. Bis zur Version 1.2.12 war die Software frei nutzbar; danach änderten sich die Lizenzbedingungen [2]. OpenSSH [3] basiert auf der letzten freien Version und wird ständig weiter entwickelt und verbessert. Zunächst ein reines OpenBSD-Projekt, ist OpenSSH mittlerweile auch für andere Unix-Plattformen verfügbar und spricht seit Version 2.1.0 beide SSH-Protokolle 1.X und 2.X. OpenSSH benutzt die Krypto-Routinen von OpenSSL [5]. Die meisten Linux-Distributionen kommen standardmäßig mit OpenSSH:

huhn@asteroid:~$ ssh -V
OpenSSH_3.4p1 Debian 1:3.4p1-1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f

Richtig verbunden

Zu SSH gehören auf der Client-Seite ssh/slogin als funktionaler Ersatz für telnet, rlogin oder rsh sowie scp zum Kopieren von Dateien (ersetzt ftp und rcp). Der Server ist der sshd (SSH-Daemon). Darüber hinaus gibt es Administrationswerkzeuge wie z. B. ssh-keygen (zum Erzeugen von Schlüsseln), ssh-agent (zur Verwaltung dieser Keys, Automatisierung und Vereinfachung des Logins), ssh-add (Registrierung neuer Schlüssel beim SSH-Agent) und make-ssh-known-hosts (Erstellung einer Liste mit bekannten öffentlichen Host-Keys einer Domain). ssh muss sowohl auf Ihrem eigenen Rechner wie auch auf der Gegenseite installiert sein; genauer: Um eine Verbindung von A nach B aufzubauen, muss auf Rechner A die Client-Software und auf B der Daemon installiert sowie letzterer auch aktiviert sein.

Um eine gesicherte Verbindung zu einem anderen Rechner aufzubauen, tippen Sie

huhn@asteroid:~$ ssh UserID@RemoteHost

oder

huhn@asteroid:~$ ssh -l UserID RemoteHost

wobei die Userid@ nur angegeben werden muss, wenn der Benutzername auf dem anderen System von dem Ihres eigenen Rechners abweicht. Beim Verbindungsaufbau (TCP-Verbindung, Port 22) tauschen Rechner A und B die jeweils verwendete Protokoll-Version aus. Ist diese nicht kompatibel, bricht die Verbindung zusammen:

Protocol major versions differ: 2 vs. 1

Mit den Optionen -1 oder -2 lässt sich aber problemlos auf die richtige Version umschalten. An den ssh-Aufruf darf direkt ein auszuführender Befehl angehängt werden. Diesen setzt man am besten in Anführungszeichen, damit die eigene Shell ihn nicht auswertet:

huhn@asteroid:~$ ssh plutarch "ls uni"
huhn@plutarch's password:
anglistik/   germanistik/

Auch Anwendungen, die die Bildschirmsteuerung selbst übernehmen, lassen sich remote starten. Dazu brauchen Sie allerdings einen zusätzlichen Parameter, um ein “Pseudo-Terminal” zu erschaffen. Mit der Option -t verschlüsselt SSH die Ausgabe des Terminals und zeigt sie im eigenen Fenster wieder entschlüsselt an:

huhn@asteroid:~$ ssh -t plutarch "mutt"

Um X-Anwendungen zu verschlüsseln und auf einem entferten Rechner zu starten, muss sowohl auf der Client- als auch auf der Server-Seite das X-Forwarding eingeschaltet sein. Die Konfigurationsdatei für den Server heißt sshd_config und findet sich im Verzeichnis /etc/ssh. Wie alle systemweiten Einstellungen darf sie nur vom Administrator root verändert werden. Der entsprechende Eintrag lautet

X11Forwarding yes

Die Konfigurationsdatei des SSH-Clients liegt im selben Verzeichnis und heißt ssh_config (ohne “d”). Bei den meisten Distributionen findet sich

#   ForwardX11 no

auskommentiert durch das Raute-Zeichen #. Um das Forwarding dauerhaft einzuschalten, setzen Sie (wiederum als root) die Zeile auf

ForwardX11 yes

Alternativ lässt sich dieses Feature durch den Einsatz der Option -X temporär aktivieren. Um eine X-Anwendung remote zu starten, loggen Sie sich entweder mit ssh [UserID@]RemoteHost oder ssh -X [UserID@]RemoteHost ein und starten diese dann auf der Kommandozeile:

huhn@asteroid:~$ mozilla &

Das Ampersand-Zeichen & stellt den Prozess dabei in den Hintergrund – das Terminal ist also wieder “frei”, um weitere Befehle anzunehmen und/oder Anwendungen zu starten. Praktischerweise wird die Variable DISPLAY gleich beim X-Forwarding richtig gesetzt – die Verbindung ist also nicht nur sicher, sondern auch unkompliziert.

Sicher transportiert

Das zweite große Anwendungsgebiet von SSH neben dem geschützten Login ist der Dateitransfer: Hier ersetzt das Tool scp (“secure copy”) die ungeschützten Dienste ftp (“file transfer protocol”) und rcp (“remote copy”). Eine Datei per scp zu kopieren, ist fast so einfach wie das normale, lokale Kopieren mit cp; ein Beispiel-Aufruf sieht etwa so aus:

huhn@asteroid:~$ scp datei UserID@RemoteHost:

Stimmen die Benutzernamen überein, darf (wie beim ssh-Aufruf) UserID weggelassen werden. Soll die Datei nicht einfach ins Home-Verzeichnis kopiert werden, hängen Sie den Pfad einfach hinter den Doppelpunkt (scp datei UserID@RemoteHost:/tmp/archiv/).

Ganze Verzeichnisbäume rekursiv kopieren Sie mit dem Parameter -r; auch die von cp bekannte Option -p (“preserve”; Rechte und Besitzer/Gruppe erhalten) darf hier verwendet werden. Das ist natürlich nur sinnvoll, wenn User- und Group-IDs auf beiden Systemen identisch sind.

Der eigene Schlüssel

Wollen Sie nicht nur gelegentlich sondern häufig Dateien zwischen Rechnern übertragen oder sich auf einem anderen System anmelden, so kann die ständige Passwortabfrage des Zielsystems störend sein; auch eine Automatisierung von Standardaufgaben über Skripte scheitert am interaktiven Element der Passworteingabe. Hier bietet SSH die Möglichkeit, einen Schlüssel auf dem Zielsystem zu hinterlegen, über den Ihre Berechtigung zum Login nachgeprüft werden kann, ohne ein Passwort zu verlangen. Das Programm ssh-keygen erzeugt einen solchen Schlüssel (englisch: “key generation”).

Für Protokollversion 1.X sind dies RSA-Schlüssel, Version 2.X verwendet stattdessen DSA-Verschlüsselung. Welcher Schlüssel erzeugt werden soll, verraten Sie dem Programm mit der Option -t. Listing 1 zeigt, wie Sie einen DSA-Schlüssel generieren.

huhn@asteroid:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/huhn/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/huhn/.ssh/id_dsa.
Your public key has been saved in /home/huhn/.ssh/id_dsa.pub.
The key fingerprint is:
72:d5:ad:76:cf:e4:89:a0:8e:f9:57:66:87:55:cd:cc huhn@asteroid

Die “Passphrase”, nach der hier zwei mal gefragt wird, hat nichts mit dem Passwort auf dem Zielsystem oder Ihrem lokalen Passwort zu tun – vielmehr können Sie mit Hilfe der Passphrase Ihr Schlüsselpaar (bestehend aus einem öffentlichen und einem geheimen Schlüssel, dazu gleich mehr) schützen. Ein solcher Schutz ist z. B. beim Einsatz von SSH auf einem Notebook sinnvoll, denn sollte das Notebook gestohlen werden und sich auf diesem ein ungeschützter SSH-Key befinden, so kann dieser zum Einbruch in ein anderes System verwendet werden.

In Ihrem Home-Verzeichnis befindet sich nun ein neues Unterverzeichnis .ssh (mit führendem Punkt), das u. a. das bereits erwähnte Schlüsselpaar, bestehend aus id_dsa und id_dsa.pub enthält. Die erste Datei ist Ihr geheimer, privater Schlüssel (eine binäre Datei, die sich nicht im Editor lesen lässt); die zweite Datei mit der Endung .pub ist der öffentliche (public) Schlüssel. Dieser kann nun auf einen Zielrechner kopiert werden, um künftig eine automatische Anmeldung auf diesem System zu ermöglichen. Das geht folgendermaßen:

• Kopieren Sie (z. B. mit scp) die Datei ~/.ssh/id_dsa.pub ins Home-Verzeichnis des Zielrechners: scp ~/.ssh/id_dsa.pub [UserID@]RemoteHost:
• Loggen Sie sich dann auf dem Zielrechner ein. Prüfen Sie, ob dort bereits ein Unterverzeichnis .ssh existiert; wenn nicht, legen Sie es an: mkdir ~/.ssh
• Wechseln Sie (auf dem Zielrechner) in das Verzeichnis (cd ~/.ssh) und hängen Sie die vom ersten Rechner kopierte Datei an die (eventuell bereits vorhandene) Datei authorized_keys an; das geht mit dem Befehl cat ~/id_dsa.pub >> authorized_keys (Sollte die Datei noch nicht vorhanden sein, wird sie von diesem Aufruf erzeugt.)
• Löschen Sie schließlich die nun nicht weiter benötigte Datei id_dsa.pub im Hauptverzeichnis (nur da!): rm ~/id_dsa.pub

Auf dem Zielrechner müssen die Rechte des .ssh-Verzeichnisses korrekt gesetzt sein: Das Verzeichnis selbst muss mit den Rechten 700 ausgestattet sein (also lesbar, schreibbar, betretbar durch den Besitzer und niemand sonst). Darüber hinaus dürfen für das Home-Verzeichnis keine Schreibrechte für Gruppe (g) und Andere (o) gesetzt sein; führen Sie im Zweifelsfall die Befehle

huhn@asteroid:~$ chmod go-w ~
huhn@asteroid:~$ chmod 700 ~/.ssh

aus. Um das Abfragen der für den Schlüssel gesetzten Passphrase zu automatisieren, gibt es die Programm ssh-agent und ssh-add. Der SSH-Agent merkt sich einmal (über ssh-add) eingegebene Passphrases, so dass bei Aufrufen von ssh keine Fragen mehr gestellt werden. Das ist vor allem dann nützlich, wenn Sie häufig die SSH-Verbindung abbrechen und wieder neu aufbauen.

In einem ersten Schritt muss der SSH-Agent gestartet werden. Er gibt als Rückgabewert eine Reihe von Befehlszeilen, die dann kopiert und ebenfalls ausgeführt werden müssen: Damit werden einige Umgebungsvariablen gesetzt.

huhn@asteroid:~$ ssh-agent 
SSH_AUTH_SOCK=/tmp/ssh-XXO0M4II/agent.32162; export SSH_AUTH_SOCK;
SSH_AGENT_PID=32163; export SSH_AGENT_PID;
echo Agent pid 32163;

Diese Prozedur, ssh-agent die Befehlszeilen ausgeben zu lassen, dient hier aber nur dem Verständnis; im praktischen Einsatz können Sie die Ausgabe von ssh-agent einfach durch eval auswerten lassen, so dass sich die Vorgehensweise auf ein einfaches

eval `ssh-agent`

verkürzt. Erst wenn der Agent läuft, kann auch ssh-add verwendet werden.

huhn@asteroid:~$ ssh-add -l
The agent has no identities.

Beim Aufruf ohne Parameter sucht es im Verzeichnis ~/.ssh nach privaten Schlüsseln und fordert Sie für jeden gefundenen auf, die zugehörige Passphrase einzugeben.

huhn@asteroid:~$ ssh-add 
Enter passphrase for /home/huhn/.ssh/id_dsa: @L: *@L: *@L: *@L: *@L: *
Identity added: /home/huhn/.ssh/id_dsa (/home/huhn/.ssh/id_dsa)

Danach kennt das Programm die Passphrase:

huhn@asteroid:~$ ssh-add -l
1024 f3:c9:b6:5d:23:3a:9d:61:50:19:63:3c:e8:22:7c:86 /home/huhn/.ssh/id_dsa (DSA)

Ab sofort können Sie (aus der laufenden Shell und allen weiteren Shells, in denen Sie die Variablen SSH_AUTH_SOCK und SSH_AGENT_PID richtig gesetzt haben) sich ohne Passworteingabe auf den Zielrechnern anmelden.