© scyther5, 123RF

Es gibt kaum einen Linux-Nutzer, der sich nicht per Secure Shell auf entfernten Rechnern anmeldet und arbeitet wie auf lokalen. SSH kann aber noch mehr – das Programm verschickt Kommandos, leitet andere TCP-Verbindungen durch einen verschlüsselten Tunnel und beherrscht Multiplexing.

Die Manpages der Open-SSH-Tools [1] lesen sich wie Romane. Die meisten Anwender kennen jedoch nur einen Bruchteil der Optionen, und auch dieser Artikel muss sich auf einige wenige Features beschränken. Dabei sind Tipps zum SSH-Multiplexing, zum Tunnelbau und zu diversen Konfigurationsdateien.

Auf Kommando!

Einer der ältesten SSH-Tricks ist es, schon beim Aufruf einen Befehl zu definieren, den SSH auf der Gegenseite ausführt – das spart Zeit und Tipparbeit. Die Ausgabe erscheint im lokalen Terminal:

heike@home:~$ ssh huhn@example.com pwd
/home/huhn

Das Kommando zeigt das Verzeichnis an, in dem sich der Benutzer »huhn« nach dem Einloggen auf dem Rechner »example.com« befindet, also im eigenen Home. Auch das Absetzen mehrerer Befehle ist möglich. Dabei ist es wichtig, Hochkommata zu setzen, um die Kommandos wirklich alle auf dem entfernten System auszuführen:

heike@home:~$ ssh huhn@example.com pwd;whoami
/home/huhn
heike
heike@home:~$ ssh huhn@example.com 'pwd; whoami'
/home/huhn
huhn

Sofern SSH auf dem anderen Rechner Befehle absetzen soll, die eine Interaktion des Benutzers erfordern, ist weiterhin die Option »-t« zum Starten eines Pseudo-Terminals nötig. Das sorgt dafür, dass Benutzer so lange eingeloggt bleiben, bis das auszuführende Programm beendet ist. Auf diese Weise können sie etwa Dateien mit einem Texteditor bearbeiten, mit »top« die laufenden Programme auflisten oder Logfiles mit »tail -f« betrachten (Abbildung 1).

Abbildung 1: Der SSH-Schalter »-t« ermöglicht eine Interaktion des Benutzers auf der Gegenseite.

Gut eingerichtet

Wer mit etlichen Accounts auf entfernten Servern jongliert, die auf unterschiedlichen Ports lauschen oder jeweils ein anderes SSH-Schlüsselpaar zur Authentisierung verwenden, kann die Optionen jedes Mal beim Aufruf angeben. Komfortabler ist jedoch eine eigene Konfigurationsdatei »~/.ssh/config« (Listing 1). Jede Zeile enthält ein Schlüsselwort; es folgen eines oder mehrere Argumente. Neben Optionen, die nur für einen Rechner gelten (Abschnitte nach »Host Name«), sind auch globale Einstellungen (»Host *«) möglich. Da SSH die Angaben der Reihe nach auswertet, stehen die allgemeinen Einstellungen am Ende der Datei. Alle Optionen listet die Manpage zu »ssh_config« auf.

01 Host work
02         HostName 123.456.78.9
03         Port 2220
04         User User
05         IdentityFile ~/.ssh/id_rsa
06 Host home
07         HostName home.example.com
08         User User2
09         CheckHostIP no
10 Host *
11         ServerAliveInterval 300
12         LogLevel VERBOSE
13         Compression yes

Das Beispiel aus Listing 1 enthält zwei Blöcke für einzelne Hosts. Für den ersten Rechner (zu erreichen über das Alias »ssh work«) ist definiert, dass der SSH-Server auf Port 2220 lauscht. Außerdem sind anstelle eines Hostnamens die IP-Adresse eingetragen und der zu verwendende Schlüssel definiert, was ein Durchprobieren aller Keys verhindert – das beschleunigt den Verbindungsaufbau, wenn im Verzeichnis »~/.ssh« etliche Schlüsselpaare liegen.

Für den zweiten Rechner »home.example.com« gilt: Er ist über den Kurznamen »home« erreichbar, »CheckHostIP no« verhindert das Abgleichen der IP-Adresse mit der Datei »~/.ssh/known_hosts«, was bei Hosts mit wechselnden, dynamisch vergebenen IPs hilfreich ist.

Bei den allgemeinen Anweisungen sorgt »ServerAliveInterval 300« dafür, dass der Client nach fünf Minuten ein Paket an den Server schickt, um die Verbindung aufrechtzuerhalten und einen Timeout zu verhindern. Außerdem ist das Log-Verhalten definiert; Anwender können zwischen »QUIET«, »FATAL«, »ERROR«, »INFO« (Standard), »VERBOSE«, »DEBUG«, »DEBUG1«, »DEBUG2« und »DEBUG3« wählen.

Die Datenkomprimierung ist in diesem Fall ebenfalls für alle Hosts eingeschaltet, was jedoch nur dann sinnvoll ist, wenn der Anwender immer mit einer langsamen Verbindung zu kämpfen hat.

Gebündelt sind wir stark

Für einen Geschwindigkeitsvorteil sorgt das Multiplexing-Feature, das mehrere Signale über eine TCP-Verbindung schicken kann. Dabei verwendet der SSH-Client eine bereits existierende Verbindung zum SSH-Server, wodurch der Handshake mit der Gegenstelle entfällt. Der Zeitgewinn entsteht also nicht bei der ersten SSH-Sitzung, sondern ab der zweiten. Anwender steuern das Multiplexing über die beiden Optionen »ControlMaster« und »ControlPath«:

ssh -o ControlMaster=yes -o ControlPath=~/.ssh/control-%h_%p_%r user@example.org

Die Anweisung »ControlMaster=yes« erzeugt eine Masterverbindung, welche die anderen Sitzungen mit demselben Ziel mitbenutzen dürfen. »ControlPath« definiert den dazu nötigen Socket; der Dateiname setzt sich aus »control«, dem Hostnamen (»%h«), dem Port (»%p«) und dem Benutzernamen (»%r«) des Zielrechners zusammen. Für die nächste Verbindung zu diesem Host geben Anwender den Socket an; »ControlMaster« bleibt auf der Voreinstellung (»no«):

ssh -o ControlPath=~/.ssh/control-%h_%p_%r user@example.org

Die zweite Verbindung versucht sich an die erste dranzuhängen. Sollte das nicht gelingen, baut der SSH-Client als Fallback-Lösung eine normale Verbindung auf. Listing 2 zeigt zum Vergleich, welche Zeit »time« für das Kommando »who« auf dem entfernten Rechner gemessen hat – einmal ohne und einmal mit aktiviertem Multiplexing. Im kleinen Testsetup ist der Unterschied nicht besonders beeindruckend, bei größeren Umgebungen dürfte sich das Feature aber positiv bemerkbar machen.

01 $ time ssh huhn@example.com who
02 [...]
03 real    0m0.288s
04 user    0m0.008s
05 sys     0m0.012s
06 [Multiplexing eingeschaltet]
07 $ time ssh huhn@example.com who
08 [...]
09 real    0m0.037s
10 user    0m0.000s
11 sys     0m0.004s

Die Multiplexing-Konfiguration muss nicht zwingend über den Schalter »-o« erfolgen, sie fühlt sich auch in der SSH-Einrichtungsdatei wohl. Außer den Anweisungen »ControlMaster« und »ControlPath« definieren Anwender hier optional »ControlPersist«, was bestimmt, wie lange die Masterverbindung im Hintergrund auf Clients wartet, nachdem die erste Verbindung beendet ist. Benutzer tragen entweder »no« (Master wartet nicht), »yes« (Master wartet ewig) oder eine Zeitdauer in Sekunden ein. Listing 3 zeigt ein Beispiel.

01 Host example
02         HostName example.com
03         ControlMaster auto
04         ControlPath ~/.ssh/control-%h_%p_%r
05         ControlPersist yes

Übrigens profitieren nicht nur SSH-Clients von dem Multiplexing-Feature, sondern auch »scp«, »rsync«, »git« und andere Kommandos, die das SSH-Protokoll nutzen.

Bitte mit X!

SSH kann grafische Programme, die auf einem entfernten Rechner laufen, zum eigenen Desktop übertragen. Vorausgesetzt der SSH-Server der Gegenseite erlaubt das X-Forwarding (»X11Forwarding yes« in der »/etc/ssh/sshd_config«) und das Paket »xauth« ist installiert, können Anwender einmalig per »ssh -X« oder dauerhaft mit einem Eintrag in der Konfigurationsdatei (»ForwardX11 yes«) X11-Programme auf dem entfernten Rechner starten und lokal steuern.

Interessant wird das Ganze, wenn mehrere Rechner beteiligt sind. Angenommen »host1« darf auf »host2« zugreifen, »host2« auf »host3«, die direkte Verbindung zwischen »host1« und »host3« ist aber nicht möglich. Statt mehrerer Kommandos geben Nutzer einen einzigen Befehl ein (Abbildung 2):

Abbildung 2: Das Programm »xeyes« läuft auf dem dritten Host namens »Sion«; die Anzeige findet jedoch in der grafischen Oberfläche des ersten Rechners (»jessie«) statt.

ssh -t -X host2 ssh -t -X host3 xeyes &

Auch hier kommt »-t« zum Einsatz (siehe Abschnitt “Auf Kommando!”). Wer ein Alias in die Konfigurationsdatei eintragen möchte, definiert für »host2« und »host3« die Option »ForwardX11 yes«. Der dritte Rechner erhält zudem die Anweisung für das »ProxyCommand« (Listing 4).

01 Host host2
02         HostName host2.example.com
03         User User
04         IdentityFile ~/.ssh/id_rsa
05         ForwardX11 yes
06 Host host3
07         HostName host3.example.com
08         User User
09         ForwardX11 yes
10         ProxyCommand ssh host2 -W %h:%p

Die Secure Shell leitet auf Wunsch andere TCP-Verbindungen durch einen sicheren Tunnel. Ähnlich wie ein Proxy nimmt SSH auf einem Port der einen Seite die Verbindung entgegen und verknüpft sie mit einem Port auf der Gegenstelle.

In der Röhre

Dieses Port-Forwarding funktioniert in beide Richtungen. Local-Port-Forwarding benötigt den Schalter »-L« und leitet eine Verbindung, die auf einem frei wählbaren lokalen Port eintrifft, durch den SSH-Tunnel zu einem Port auf einem entfernten Server weiter:

ssh -L Local_port:localhost:Remote_portUser@Remote_host

Anwender können mit einem solchen Tunnel Restriktionen auf der Gegenseite umgehen und beispielsweise einen MySQL-Server, der nur auf lokalen Verbindungen lauscht (»bind-address = 127.0.0.1«) vom lokalen Rechner aus erreichen (Abbildung 3).

Abbildung 3: Im grafischen MySQL-Client definieren Anwender als Adresse des entfernten MySQL-Servers »127.0.0.1« und die vorher im Tunnel angegebene Portnummer (hier »3307«).

Auch umgekehrt ist das Tunneln möglich: Beim Remote-Port-Forwarding kommt die Verbindung auf einem Port des entfernten Rechners an, und über den SSH-Tunnel gelangen die Daten weiter zu einem beliebigen Port auf der Client-Seite. Anwender machen sich das Feature zunutze, um einen Dienst eines Rechners aus dem lokalen Netz mit anderen zu teilen, die außerhalb des LAN sind.

Anstelle von »-L« kommt diesmal der Schalter »-R« zum Einsatz:

ssh -R Remote_port:localhost:Local_portUser@Remote_host

Damit das klappt, muss auf dem SSH-Server der Gegenseite die Option »GatewayPorts yes« gesetzt sein, damit entfernten Rechnern die Verbindung zu lokalen, weitergeleiteten Ports gestattet ist. Abbildung 4 zeigt ein Beispiel, in dem der Webserver (Port 80) eines Raspberry Pi (der nur im lokalen Netz verfügbar ist) über einen SSH-Tunnel mit dem Port 9000 eines entfernten Servers verbunden ist. Dieser hat eine öffentliche IP-Adresse, so ist der Webserver über Port 9000 nun auch von außen erreichbar.

Abbildung 4: Ein lokaler Webserver ist über den SSH-Tunnel nun von außen über Port 9000 zu erreichen.

Wer die Einstellungen für einen oder mehrere SSH-Tunnel in der Konfigurationsdatei hinterlegen möchte, findet ein Beispiel in Listing 5.

01 Host host1
02         HostName host1.example.com
03         LocalForward 3307 localhost:3306
04 Host host2
05         HostName host2.example.com
06         RemoteForward 9000 localhost:80