Sur ma machine locale, je lance :
ssh -X [email protected]
(Pour être complet, j'ai également testé tous les éléments suivants en utilisant -Y avec des résultats identiques).
Comme prévu, cela accède bien à remotemachine.com, et tout semble bien. Si j'essaie ensuite d'exécuter xcalc, j'obtiens :
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0
Mais,
$ 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
Donc, non seulement /tmp/.X11-unix/X0 existe, mais il a des permissions universelles r/w/x !
J'ai déjà utilisé x-forwarding sans problème, mais pas depuis un certain temps…
uname -a sur le serveur pour référence :
Linux machinename 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux
Cela fait quelques heures que je cherche sur le web sans succès. Autres mentions du même problème, mais aucune solution.
Réponse acceptée :
Si vous avez un serveur X en cours d'exécution et que le DISPLAY la variable d'environnement est définie sur :0 , qui indique aux applications de se connecter au serveur X en utilisant un socket de domaine unix qui se trouve généralement sous Linux dans /tmp/.X11-unix/X0 (bien que voir ci-dessous à propos de l'espace de noms abstrait sur Linux récent).
Lorsque vous vous connectez en ssh à la machine remotemachine , sshd sur ordinateur distant définit DISPLAY sur localhost:10 (par exemple), ce qui signifie cette fois que les connexions X doivent être effectuées via TCP vers le port 6010 de la machine localhost. sshd sur machine distante écoute les connexions là-bas et transmet toute connexion entrante au client ssh. Le client ssh essaie alors de se connecter à /tmp/.X11-unix/X0 (du côté local, pas du côté distant) pour contacter votre serveur X.
Maintenant, peut-être que vous n'avez pas de serveur X en cours d'exécution (êtes-vous sur Mac ?) Ou peut-être que le socket de domaine unix ne se trouve pas dans /tmp/.X11-unix, ce qui signifierait que ssh n'a pas été configuré correctement à la compilation temps.
Pour déterminer quel est le bon chemin pour le socket unix, vous pouvez essayer un strace -e connect xlogo (ou l'équivalent sur votre système) sur votre machine locale pour voir ce que fait une application X normale.
netstat -x | grep X peut aussi donner un indice.
Pour mémoire, sur une machine sifflante Linux Debian ici, Xorg écoute à la fois sur /tmp/.X11-unix/X0 dans le système de fichiers et /tmp/.X11-unix/X0 sur l'espace de noms abstrait (généralement écrit @/tmp/.X11-unix/X0 ). De strace , les applications X11 semblent maintenant utiliser cet espace de noms abstrait par défaut, ce qui explique pourquoi celles-ci fonctionnent toujours si /tmp/.X11-unix est supprimé, tandis que ssh n'utilise pas cet espace de noms abstrait.