在本地计算机上，我运行：
ssh -X [email protected]
（为完整起见，我还使用-Y测试了以下所有程序，并得到了相同的结果）。
如预期的那样，可以很好地访问remotemachine.com，并且一切正常。但是，如果我随后尝试运行xcalc，则会得到：
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0
但，
$ 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
因此，不仅/tmp/.X11-unix/X0存在，而且具有通用的r / w / x权限！
我以前曾经使用过x-forwarding没问题，尽管有一段时间了...
服务器上的uname -a供参考：
Linux machinename 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux
现在已经在网上搜索了两个小时，但没有成功。其他提到相同的问题，但没有解决方案。
如果您正在运行X服务器，并且DISPLAY环境变量设置为:0，则会告诉应用程序使用通常在Linux中找到的unix域套接字连接到X服务器/tmp/.X11-unix/X0（尽管有关最新Linux上的抽象名称空间的信息，请参见下文） 。
当您将ssh连接到machine remotemachine时，例如，sshd在remotemachine上将DISPLAY设置为DISPLAY localhost:10，这意味着X连接是通过TCP完成到计算机localhost的端口6010的。remotemachine上的sshd侦听那里的连接，并将任何传入的连接转发到ssh客户端。然后，ssh客户端尝试连接/tmp/.X11-unix/X0（在本地端，而不是远程）以联系您的X服务器。
现在，也许您没有运行X服务器（在Mac上运行吗？），或者在/tmp/.X11-unix中找不到Unix域套接字，这意味着ssh在编译时未正确配置时间。
要弄清楚unix套接字的正确路径，可以strace -e connect xlogo在本地计算机上尝试一个（或系统上的等效路径）以查看普通X应用程序的作用。
netstat -x | grep X 可能还会提供一些线索。
根据记录，在Linux Debian的喘息机在这里，Xorg的侦听都/tmp/.X11-unix/X0在文件系统中，并/tmp/.X11-unix/X0在抽象名字空间（一般写@/tmp/.X11-unix/X0）。从中strace，X11应用程序现在似乎默认情况下使用该抽象名称空间，这解释了为什么如果/tmp/.X11-unix删除了这些名称空间，而仍然ssh不使用该抽象名称空间，为什么它们仍然可以工作。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句