Auf meinem lokalen Rechner führe ich Folgendes aus:
ssh -X [email protected]
(Der Vollständigkeit halber habe ich auch alles Folgende mit -Y mit identischen Ergebnissen getestet).
Wie erwartet greift dies problemlos auf remotemachine.com zu, und alles scheint in Ordnung zu sein. Wenn ich dann versuche, xcalc auszuführen, erhalte ich jedoch:
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0
Aber,
$ ls -la /tmp/.X11-unix/
total 36
drwxrwxrwt 2 root root 4096 2012-11-23 09:29 .
drwxrwxrwt 8 root root 32768 2012-11-29 08:22 ..
srwxrwxrwx 1 root root 0 2012-11-23 09:29 X0
Es existiert also nicht nur /tmp/.X11-unix/X0, es hat auch universelle R/W/X-Berechtigungen!
Ich habe X-Forwarding früher ohne Probleme verwendet, wenn auch seit einiger Zeit nicht mehr …
uname -a auf dem Server als Referenz:
Linux machinename 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux
Suche jetzt seit ein paar Stunden erfolglos im Netz herum. Andere Erwähnungen des gleichen Problems, aber keine Lösungen.
Akzeptierte Antwort:
Wenn Sie einen X-Server laufen haben und die DISPLAY Umgebungsvariable ist auf :0 gesetzt , der Anwendungen mitteilt, sich mit dem X-Server über einen Unix-Domain-Socket zu verbinden, der unter Linux im Allgemeinen in /tmp/.X11-unix/X0 zu finden ist (obwohl siehe unten über den abstrakten Namensraum auf aktuellem Linux).
Wenn Sie eine SSH-Verbindung zur Maschine remotemachine herstellen , sshd auf remotemachine setzt DISPLAY auf localhost:10 (zum Beispiel), was dieses Mal bedeutet, dass X-Verbindungen über TCP zu Port 6010 des Computers localhost hergestellt werden. sshd auf remotemachine lauscht dort auf Verbindungen und leitet jede eingehende Verbindung an den ssh-Client weiter. Der ssh-Client versucht dann, sich mit /tmp/.X11-unix/X0 zu verbinden (am lokalen Ende, nicht am entfernten), um Ihren X-Server zu kontaktieren.
Nun, vielleicht haben Sie keinen X-Server am Laufen (sind Sie auf einem Mac?) oder vielleicht ist der Unix-Domain-Socket nicht in /tmp/.X11-unix zu finden, was bedeuten würde, dass ssh beim Kompilieren nicht richtig konfiguriert wurde Zeit.
Um herauszufinden, was der richtige Pfad für den Unix-Socket ist, könnten Sie einen strace -e connect xlogo versuchen (oder das Äquivalent auf Ihrem System) auf Ihrem lokalen Rechner, um zu sehen, was eine normale X-Anwendung tut.
netstat -x | grep X kann auch einen Hinweis geben.
Fürs Protokoll, auf einer Linux-Debian-Wheezy-Maschine hier hört Xorg sowohl auf /tmp/.X11-unix/X0 im Dateisystem und /tmp/.X11-unix/X0 auf dem abstrakten Namensraum (allgemein geschrieben @/tmp/.X11-unix/X0 ). Aus strace , scheinen X11-Anwendungen diesen abstrakten Namensraum jetzt standardmäßig zu verwenden, was erklärt, warum diese immer noch funktionieren, wenn /tmp/.X11-unix entfernt wird, während ssh verwendet diesen abstrakten Namensraum nicht.