Esto complementa otras respuestas con información específica de Windows-Subsystem para Linux. La respuesta aceptada es correcta: su DISPLAY
variable está configurada incorrectamente. Sin embargo, no está exactamente claro por qué ese es el caso solo de esa respuesta, por lo que estoy remediando con esta respuesta.
Si está ejecutando cygwin, o Windows-Subsystem para Linux, y su servidor X11 está basado en Windows (por ejemplo VcXsrv
, o XMing
), es más probable que su servidor X11 esté escuchando en un puerto TCP (como 127.0.0.1
en los puertos TCP 6000-6010
) que en el socket de dominio predeterminado de Unix (/tmp/.X11-unix/X0
). Los sockets Unix no son compatibles con Windows en este momento, incluso dentro de WSL. La comunicación entre programas en el entorno similar a Linux y programas que se ejecutan directamente en el host de Windows también es generalmente más fácil a través de sockets IP.
Cuando ejecuta aplicaciones gráficas localmente (es decir, desde el entorno Cygwin o WSL de su host), y su DISPLAY
variable se establece en el valor predeterminado (es decir DISPLAY=:0.0
), las aplicaciones primero intentarán conectarse al servidor X a través del socket Unix /tmp/.X11-unix/X0
. Esto fallará, pero la mayoría de las aplicaciones recurrirán a una conexión TCP activada localhost
, que debería llegar al servidor, suponiendo que su servidor X esté configurado con los valores predeterminados.
Puede confirmar que esto está sucediendo buscando connect()
llamadas en registros de una ejecución de su aplicación gráfica. En general, eso sucedería desde el principio, antes de que aparezca la ventana principal de la aplicación.
Ese comportamiento alternativo no ocurre cuando ssh está redirigiendo una conexión desde el lado remoto, por lo que obtiene ese error. sshd
de hecho está reenviando la conexión al lado local, pero la conexión local del cliente ssh llega a un punto muerto ya que no puede llegar al servidor a través del socket Unix. Entonces obtienes el ENOENT
error.
En tales casos, cambiar su DISPLAY
variable para usar la sintaxis TCP en lugar de la :0.0
sintaxis, puede solucionar el problema:
DISPLAY=127.0.0.1:0 ssh remote some-gui-application
Como mencionan otras respuestas, también puede exportar esa variable de manera interactiva desde su indicador de shell:
$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application
También puede almacenar esta configuración de manera más permanente agregando esa línea a su script de inicialización del perfil de shell de inicio de sesión (por ejemplo ~/.bash_profile
).
Nota: Algunos shells tienen un script de inicialización diferente para las sesiones de inicio de sesión y no inicio de sesión. Por ejemplo, con bash podría escribir esa línea en el script sin inicio de sesión, es decir ~/.bashrc
, en lugar de ~/.bash_profile
. Si lo hace, tenga cuidado de no anular ningún valor personalizado que ssh haya establecido. Ese sería el caso si saltaras primero a tu host a través de ssh y luego saltaras nuevamente a otro host (anidando así tu reenvío X11).
strace -fo /tmp/trace ssh....
comprobar que intenta conectar ese socket de dominio Unix.