Mit SSH kann man die X11-Bildschirmausgabe eines entfernt gestarteten Programms problemlos auf sein lokales Display umleiten. Dabei tunnelt und verschlüsselt SSH die übertragenen Bildinhalte und Eingaben. Beim Zugriff auf einen virtuellen Linux-Server kann das jedoch daran scheitern, dass dort das Erstellen bestimmter Socket-Typen nicht gestattet ist.

Normalerweise ist die Umleitung der grafischen Ausgabe eines entfernten Servers denkbar einfach:

ssh -YC benutzername@server.com

Der Parameter “-X” sagt SSH, dass es beim Verbindungsaufbau gleich die Weiterleitungen von X11-Daten vorbereiten und die DISPLAY-Variable setzen soll und die übertragenen Daten komprimiert (“-C”).

Damit das funktioniert, muss die Weiterleitung auf dem Server in der /etc/ssh/sshd_config mit folgender Zeile aktiviert sein:

X11Forwarding yes

Verbindet man sich nun mit aktiviertem Debug-Logging mit dem Server …

ssh -YCvvv benutzername@server.com

… und sieht in den vorbeifliegenden Zeilen diese …

debug1: channel 1: new [x11]
debug1: confirm x11
debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
debug2: channel 1: read failed

… dann hat man ein Problem: Die X11-Weiterleitung funktioniert nicht.

~$ xterm
X11 connection rejected because of wrong authentication.
xterm Xt error: Can't open display: localhost:11.0

Bei mir ist das Ziel der Verbindung ein virtueller Linux-Server (“VServer”) der Firma vollmar.net. Ein Blick ins SSH-Protokoll auf Server-Seite (/var/log/auth.log) bei aktiviertem Debug-Logging (“LogLevel DEBUG3” in die /etc/ssh/sshd_config und SSH neu starten) liefert die Erklärung:

Jan 23 16:35:24 server sshd[31844]: debug1:
  session_input_channel_req: session 0 req x11-req
Jan 23 16:35:24 server sshd[31844]: debug1:
  x11_create_display_inet: Socket family 10 not supported

Der Socket-Typ wird also nicht unterstützt. Mehr tun, als den Hoster um Hilfe zu bitten, kann man hier leider nicht.

Wenn das eigene System eine vom Ziel-Rechner erreichbare IP hat, kann man als Workaround aber den folgenden unsicheren Weg wählen:

# Lokalen DISPLAY-Port herausfinden und merken
# (die Zahl nach dem Doppelpunkt am Ende!)
echo $DISPLAY

# entfernten Hosts Zugriff auf den eigenen
# X-Server gestatten
xhost +

# normale SSH-Verbindung zum Ziel-Host aufbauen
ssh benutzername@server.com

# dort die DISPLAY-Variable auf die eigene IP
# und den lokalen Displayport setzen (hier 0)
~$ export DISPLAY=<öffentliche-Client-IP-Adresse>:0

# Ein Programm mit grafischer Ausgabe starten...
~$ xterm

Auch wenn das funktioniert: Die Verbindung ist unverschlüsselt. I told you so.