Netzwerktranparenz

Allheilmittel Secure Shell

Alle im vorhergehenden Kapitel beschriebenen X11-Sicherheitsmechanismen haben jedoch eine Schwäche gemeinsam: Ein IP-Trace, aufgezeichnet von einer beliebigen Maschine im selben Netzwerksegment, erlaubt mit geeigneten Analyse-Tools eine genaue Rekonstruktion der gesamten X-Session. Am kritischten sind dabei in der Regel die Passwörter, die zur Anmeldung am entfernten Linux-Host verwendet werden.

Die Secure Shell, kurz SSH, wurde ursprünglich als sicherer Ersatz für die leicht kompromittierbaren rsh und rlogin sowie telnet entwickelt. Die Anmeldung, mit Login und Passwort oder anhand eines geheimen Schlüssels, erfolgt abhörsicher, der gesamte Datenaustausch wird verschlüsselt. Das ist aber noch lange nicht alles.
Der SSH-Client baut eine TCP-Verbindung (in der Regel auf Port 22) zum SSH-Server - der sshd unter Linux - auf und authentifiziert den Anwender, wie gesagt bereits verschlüsselt. Nun bietet SSH nicht nur die Möglichkeit, mit der Shell auf dem entfernten Rechner zu arbeiten (wie mit telnet), sondern erlaubt darüber hinaus, beliebige andere TCP-Verbindungen in seiner verschlüsselten Verbindung zu "tunneln". Dabei fängt der SSH-Server den Datenstrom auf bestimmten, konfigurierbaren Ports entgegen, und versendet die Packete verpackt durch seine verschlüsselte Verbindung zum SSH-Client, der sie wieder entschlüsselt, auspackt und dem entsprechenden lokalen Port übergibt. SSH agiert hier als Proxy. Das ganze funktioniert auch umgekehrt, dh. der SSH-Client tunnelt bestimmte TCP-Ports zum SSH-Server, der sie dort wieder "auspackt".

X11-Forwarding durch SSH

Das Verfahren wird am konkreten Beispiel X11 deutlicher.
Zunächst muss natürlich ein X-Server laufen, dh. man sitzt vor einem beliebigen X-Desktop. Um nun durch ein SSH-Tunnel eine X-Applikation von einem entfernten Linux-Host auf den Bildschirm zu bekommen, genügt das einfache Kommando

ssh -X user@remotehost /usr/X11/bin/xterm &

Falls der User-Name auf remotehost identisch mit dem lokalen ist, kann auch die Angabe von user@ weggelassen werden. Mit -X wird SSH dazu veranlasst, den X11-Datenverkehr wie oben beschrieben zu tunneln.
Auffällig ist, dass beim Auffruf von xterm die Angabe der Display-ID fehlt. Darum kümmert sich ssh selbst: Für jeden neuen User erzeugt der SSH-Server einen virtuellen X-Server und setzt entsprechend die DISPLAY-Variable in der Shell, aus der heraus der X-Client dann gestartet wird. In der Regel erhält der erste User die Display-ID "localhost:10" - localhost deshalb, weil ja der SSH-Server aus der Sicht des X-Clients auf localhost läuft. Für jeden weiteren parallel eingelogten User wird die Display-Nummer von 10 aufsteigend eins weiter gezählt. Diese virtuellen X-Server agieren als Proxy und leiten den X11-Datenstrom komprimiert und verschlüsselt über die SSH-Verbindung (Port 22) und den SSH-Client, der diese Daten auspackt und an den X-Server (auf Port 6000) weiterleitet.

X11-Zugangskontrolle mit SSH

Natürlich wäre die ganze Anstrengung umsonst, wenn auf Seiten des SSH-Servers (des sshd) die virtuellen X-Server für jedermann offen wären. Deshalb etabliert SSH zwischen den X-Clients und dem virtuellen X-Server eine strenge Zugangskontrolle nach dem xauth-Verfahren. Mit jedem SSH-Login wird ein aktualisiertes Cookie in die .Xauthority-Datei des verwendeten UNIX-Users geschrieben. So ist kein anderer User in der Lage, mit dem entsprechenden virtuellen X-Server in Verbindung zu treten (vgl. X11 und Sicherheit).
Eben diese Absicherung kann aber zum Hindernis werden, insbesondere dann, wenn Arbeiten als Super-User root vorzunehmen sind, ein direktes Einloggen als root mit ssh aber aus Sicherheitsgründen abgeschaltet ist - was auch die Regel ist. Wie bei telnet loggt man sich zunächst als "normaler" User ein und wechselt dann mit su in den Superuser-Modus.
Soweit, so gut, nur wird es so - wegen des fehlenden Cookies in der .Xauthority-Datei von root - nicht gelingen, X-Applikationen durch den SSH-Tunnel zu bringen. Auch ist die DISPLAY-Variable nicht richtig gesetzt.
Mit wenigen Handgriffen läßt sich hier Abhilfe schaffen. Zunächst empfiehlt sich ein su -p (für "preserve-environment"), um den Inhalt der DISPLAY-Variable zu erhalten. Dann besorgt sich der Superuser, der ja alles darf, einfach das richtige Cookie mit

cd /root
cp ~user/.Xauthaurity .

Dann gelingt der Aufruf von X-Programmen als root ohne weiteres.