Vielseitig

Die Secure Shell oder ssh gehört schon seit Längerem zum Standardwerkzeug für das Arbeiten auf entfernten Rechnern. Doch ihre Fähigkeiten gehen wesentlich weiter: Zum einen beschränken sich ihre Tunnelfähigkeiten nicht auf X11-Sessions, zum anderen kann sie den Netzverkehr auf das Wesentliche reduzieren.

Denn mit der Option -C auf die Reise geschickt, komprimiert die SSH alle Daten mit dem gzip-Algorithmus. Allerdings sollte man hier auf die Ressourcen achten: Während die SSH-Kompression den Verkehr auf langsamen Verbindungen massiv beschleunigen kann - vor allem, wenn sie Grafikdaten überträgt -, kann das in schnellen Netzen das Gegenteil bewirken, wenn nämlich die CPUs als Bottleneck sich erweisen.

Ebenfalls lohnen kann sich das Komprimieren beim Kopieren ganzer Verzeichnisbäume - einfach per Pipe durch die SSH geschickt etwa mit tar cf - <localdir> | ssh -C <remotehost> „cd <remotedir> && tar xpf -“.

Einige Dämonen wie fetchmail oder exim besitzen SSH-Plug-ins, mit denen sich die Verbindung verschlüsseln lässt. rsync arbeitet inzwischen standardmäßig mit einem SSH-Tunnel. Versionen, die das nicht tun, sollten sich mit der Option -e ssh oder --rsh=ssh zum Pipen durch einen SSH-Tunnel bewegen lassen.

Eine Alternative zur Pipe bietet das Local Port Forwarding. Dafür etabliert man einen Tunnel zwischen einem freien lokalen Port und dem entfernten Zielport nach dem Muster ssh -L <localport>:<targethost>:<targetport> <user>@<authhost>. Um etwa eine Web-Session, die nicht über HTTPS angeboten wird, zu verschlüsseln, genügt der Befehl ssh -L 6080:<webserver>:80 <user>@<sshserver> in einem Terminal, danach lädt man mit dem Browser http://localhost:6080. Das Gleiche gilt für ungesicherte IMAP-, POP3-, SMTP- oder VNC-Sessions: Nach dem Etablieren des Tunnels ist in der Client-Software lediglich localhost samt gewähltem Port als Server einzutragen. Dabei müssen Anwendungs- und SSH-Server nicht auf einem Rechner liegen. Auf diese Weise lässt sich ein Teilstück einer Strecke verschlüsseln, etwa der zwischen zwei Gateways. Damit auch andere Rechner den Tunnel benutzen können, müssen sie Zugriffsrecht auf localhost:6080 besitzen. Das bewirkt die Option -g beim Einrichten des Tunnels.

In alle Richtungen

In die andere Richtung funktioniert das Remote Port Forwarding: Dort gibt man auf dem Gateway gate, der vor dem eigenen Intranet-Webserver sitzt, mit ssh -R 6080:<intranetweb>:80 <remotegate> den Intranet-Webserver als Ziel-Host an, aber den entfernten Gateway - etwa den einer Zweigstelle - als SSH-Server. Der lauscht dann auf Port 6080 auf Anfragen, die er an den SSH-Client auf gate weiterleitet, der sie wiederum an Port 80 des Intranet-Webservers weiterreicht. Damit nun alle Browser hinter dem Remote-Gateway auf den Intranet-Server zugreifen können, muss sich in der Datei /etc/ssh/sshd_config auf remotegate die Zeile GatewayPorts yes befinden.

Hat man es mit mehreren hintereinanderliegenden Firewalls zu tun, kann man die Reichweite der SSH-Tunnel dadurch erhöhen, dass man mehrere ineinander verschachtelt - jeder weitere erhöht die Reichweite um zwei Hops. Dazu ist es notwendig, den Ziel-Port der äußeren Tunnel auf den zuvor geschaffenen Einstiegspunkt der inneren mit der Option -p umzulenken. Als Beispiel dienen zwei Tunnnel, an denen insgesamt sechs Rechner beteiligt sind. Zuerst etabliert man die Weiterleitung zwischen host2 und host5, indem man auf host3 den Befehl ssh -gL 2222:host5:22 host4 absetzt. Danach benutzt man für das ssh-Kommando auf host2 den neuen ssh-Tunnel-Port 2222 auf host3 für den Zugriff auf den sshd auf host5 mit ssh -p 2222 -gL 7080:host6:80 host3. Nun wird der Web-Client host1 beim Zugriff auf host2:6080 auf den Webserver auf host6 weitergeleitet.

Für Verbindungen zu Remote-Hosts, die man des Öfteren heimsucht, lohnt sich das Einrichten von Session-Konfigurationen in der Datei ~/.ssh/config. Dort trägt man für jede Session (Host) den gewünschte Remote-Host, den zu verwendenden Benutzernamen und weitere Argumente ein, wie SSH-Version, X11-Enabling oder einen anderen SSH-Port. Auch die Einstellung zur Kompression ist dort gut aufgehoben.

Host ixhost
  HostName ixhost.heise.de
  User susanne
  Protocol 2 # Verhindert Fallback auf Version 1
  ForwardX11 yes
  Port 2222 # Spricht remote-sshd auf Port 2222 an
  Compression yes

Für ein passwortloses Anmelden sattelt man auf die Authentifizierung per RSA- oder DSA-Schlüssel um. Die Schlüsselpaare erzeugt der Befehl ssh-keygen -t [rsa|dsa] mit oder ohne Passphrase und hinterlegt sie standardmäßig in ~/.ssh/id_[rsa|dsa] und ~/.ssh/id_[rsa|dsa].pub. ssh-copy-id -i ~/.ssh/id_[rsa|dsa].pub <remote-host> kopiert die öffentlichen Schlüssel auf die Remote-Hosts und hängt sie dort jeweils an die Datei ~/.ssh/authorized_keys an. Sollte ssh-copy-id nicht vorhanden sein, bildet das Kommando cat ~/.ssh/*.pub | ssh <remote-host> 'cat >> .ssh/authorized_keys' eine annehmbare Alternative.

Hat man die Schlüssel mit Passphrase erzeugt, müsste man nun bei jedem Login die Passphrase angeben. Diese Arbeit kann man dem ssh-agent überlassen. Er speichert die bei der lokalen Anmeldung einmal eingegebene Passphrase in einem gesonderten Cache. Zur Anmeldung starten kann man ihn beispielsweise durch einen Eintrag wie test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login" etwa in der Datei ~/.profile. (sun)