在我的本地机器上，我运行：
ssh -X me@remotemachine.com
（为了完整起见，我还使用 -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
现在在网上搜索了几个小时没有成功。其他人提到了同样的问题，但没有解决方案。
m0j*_*0j0 56
我在连接到远程 Linux 服务器时遇到了与 Cygwin 和 Xming 相同的问题。
我的 $DISPLAY 变量在 Cygwin 中只是 ":0.0"，虽然它在本地工作，但它不适用于远程 ssh 命令。
在本地机器上将变量更改为“localhost:0.0”解决了这个问题。
export DISPLAY=localhost:0.0
一旦我这样做了，我的命令就起作用了：
ssh -Yf user@host gvim somefile.c
Sté*_*las 32
如果您有一个 X 服务器正在运行并且DISPLAY环境变量设置为:0，这会告诉应用程序使用通常在 Linux 上可以找到的 unix 域套接字连接到 X 服务器/tmp/.X11-unix/X0（尽管请参阅下面关于最近 Linux 上的抽象命名空间） .
当您通过 ssh 连接到机器remotemachine 时，sshd在remotemachine 上将DISPLAY 设置为localhost:10（例如），这意味着 X 连接确实通过 TCP 完成到机器 localhost 的端口 6010。远程机器上的sshd侦听那里的连接并将任何传入连接转发到 ssh 客户端。然后 ssh 客户端尝试连接到/tmp/.X11-unix/X0（在本地端，而不是远程端）以联系您的 X 服务器。
现在，也许您没有运行 X 服务器（您在 Mac 上吗？）或者也许在 /tmp/.X11-unix 中找不到 unix 域套接字，这意味着 ssh 在编译时没有正确配置时间。
要确定 unix 套接字的正确路径是什么，您可以strace -e connect xlogo在本地计算机上尝试 a （或系统上的等效路径）以查看普通 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使用，而不使用该抽象命名空间。
ini*_*_js 14
这是对 Windows-Subsystem for Linux (WSL) 中特定信息的其他答案的补充。该接受的答案是正确的：你的DISPLAY变量配置不正确。但是，目前尚不清楚为什么仅从该答案中会出现这种情况，因此我正在使用此答案进行补救。
如果您正在运行 cygwin 或适用于 Linux 的 Windows 子系统，并且您的 X11 服务器是基于 Windows 的（例如VcXsrv， 或XMing），则您的 X11 服务器更有可能正在侦听 TCP 端口（例如127.0.0.1port 6000-6010）而不是默认端口Unix 域套接字 ( /tmp/.X11-unix/X0)。Unix 套接字目前在 Windows 上并没有得到很好的支持，即使在 WSL 中也是如此。在类 Linux 环境中的程序与直接在 Windows 主机上运行的程序之间的通信通常也更容易通过 IP 套接字进行。
当您在本地运行图形应用程序（即从主机的 Cygwin 或 WSL 环境中），并且您的DISPLAY变量设置为默认值（即DISPLAY=:0.0）时，应用程序将首先尝试通过 Unix 套接字连接到 X 服务器/tmp/.X11-unix/X0。这将失败，但大多数应用程序将回退到 上的 TCP 连接localhost，假设您的 X 服务器配置为默认值，该连接应该可以成功到达服务器。
您可以通过connect()在图形应用程序的运行中查找strace 日志中的调用来确认这是否正在发生。这些通常会在应用程序的主窗口出现之前发生。
问题：当 ssh 从远程端重定向连接时，不会发生这种回退行为，因此您会收到该错误。sshd远程确实会将 X11 连接转发到本地端，但是 ssh 客户端的本地连接由于无法通过 Unix 套接字与服务器连接而陷入死胡同。然后你会得到ENOENT错误。它不会尝试与 TCP 本地主机的后备连接。
解决方法：在这种情况下，将DISPLAY变量更改为使用 TCP 语法而不是:0.0语法，可以解决问题：
DISPLAY=127.0.0.1:0 ssh remote some-gui-application
与提到的其他答案一样，您还可以从 shell 提示中交互式导出该变量：
$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application
您还可以通过将该行添加到您的登录 shell 配置文件初始化脚本（例如~/.bash_profile）来更永久地存储此设置。
注意：某些 shell 对登录和非登录会话具有不同的初始化脚本。例如，使用 bash，您可以将该行写入非登录脚本，即~/.bashrc, 而不是~/.bash_profile. 如果这样做，请注意不要覆盖任何可能已由 ssh 设置的自定义值。如果您首先通过 ssh 跳转到您的主机，然后再次跳转到另一个主机（从而嵌套您的 X11 转发），就会出现这种情况。
小智 5
如果您的显示主机恰好是macOS，请确保您正在运行XQuartz。
此错误消息告诉您 ssh 隧道正在工作，但它无法弄清楚如何连接到隧道一侧的X 服务器。
在过去的美好时光，Mac OS X曾经为您启动 XQuartz，但我们显然已经在macOS版本的终端中放弃了这个不错的小功能。