-El indicador X (reenvío X11) no parece funcionar en Windows

16

Estoy usando Open SSH (OpenSSH_6.6.1p1, OpenSSL 1.0.1i 6 de agosto de 2014) en Windows 8.1. El reenvío X11 no parece estar funcionando. La variable de entorno DISPLAY no parece estar configurada.

Por ejemplo, si uso BitVise o Putty para conectarme y ejecuto env, veo:

[marko@vm:~]$ env
XDG_SESSION_ID=6
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.1.174 61102 22
SSH_TTY=/dev/pts/0
USER=marko
MAIL=/var/mail/marko
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/home/marko
LANG=en_CA.UTF-8
NODE_PATH=/usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript
SHLVL=1
HOME=/home/marko
LANGUAGE=en_CA:en
LOGNAME=marko
SSH_CONNECTION=192.168.1.174 61102 192.168.1.64 22
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=localhost:10.0
_=/usr/bin/env

Si en cambio uso OpenSSH (ssh -X marko @ vm):

[marko@vm:~]$ env
XDG_SESSION_ID=8
TERM=cygwin
SHELL=/bin/bash
SSH_CLIENT=192.168.1.174 61150 22
SSH_TTY=/dev/pts/1
USER=marko
MAIL=/var/mail/marko
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/home/marko
LANG=en_CA.UTF-8
NODE_PATH=/usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript
SHLVL=1
HOME=/home/marko
LANGUAGE=en_CA:en
LOGNAME=marko
SSH_CONNECTION=192.168.1.174 61150 192.168.1.64 22
XDG_RUNTIME_DIR=/run/user/1000
_=/usr/bin/env
ssh x11 abendigo
fuente
1
Puede ser obvio, pero no puedo asegurarlo por su publicación: ¿realmente tiene un servidor X instalado en Windows, por ejemplo, siguiendo bitvise.com/ssh-x11-forwarding ?
1
Sí, tengo Xming X Server ( straightrunning.com/xmingnotes )
abendigo
¿Has probado, solo para probar cosas, lo mismo con PuTTY? Si no, sugiero probar con eso y ver si funciona allí.
polemon
1
Sí, funciona en masilla.
abendigo
Estoy revisando mi VM de Windows en este momento. Puede ser tan simple como verificar qué tipo de variables establece PuTTY para que esto funcione. Agregaré una respuesta en un par de horas.
polemon

Respuestas:

16

¿Ha configurado DISPLAYla variable de entorno en el cliente? No estoy seguro de qué shell está utilizando, pero con el derivado de shell Bourne (como bash), intente:

export DISPLAY=127.0.0.1:0
ssh -X marko@vm

O si está utilizando cmd.exe:

set DISPLAY=127.0.0.1:0
ssh -X marko@vm
yaegashi
fuente
¡Gracias, esto es exactamente lo que me faltaba! Otorgaré la recompensa tan pronto como se me permita.
abendigo
Tenga en cuenta que voté por la respuesta de Roaima (a continuación) porque describe por qué , además de dar una respuesta.
Azhrei
2
Entonces, la respuesta de Roaima explica por qué ocurrió el problema, pero no me ayudó a resolverlo. Le expliqué en mi pregunta que estaba ejecutando Windows. La respuesta de yaegashi me dio un comando para ingresar en Windows que resolvió mi problema. Por eso seleccioné esta respuesta.
abendigo
Registré una cuenta solo para votar esta respuesta. Había buscado en Internet mucho tiempo antes de llegar aquí.
Rio Wing
3
Esta solución no me funciona. set DISPLAY=anythingseguido de ssh -X user@remoteretornos CreateProcessW failed error:2 ssh_askpass: posix_spawn: No such file or directory Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).Desarmar la variable de entorno con set DISPLAY=me permite ssh con éxito nuevamente, pero sin trabajar el reenvío X. No tiene ningún sentido para mí que la configuración de DISPLAY haga que el software solicite mi contraseña de esta manera. github.com/PowerShell/Win32-OpenSSH/issues/1088 github.com/PowerShell/Win32-OpenSSH/issues/1088
Pavel Komarov
14

Cuando corres ssh -X remotehosty te DISPLAY=localhost:10presentan al host remoto. sshescucha en ese puerto y reenvía el tráfico al sistema de llamada, utilizando su valor original de DISPLAYpara determinar la dirección del servidor.

Es probable que en su sistema local tenga DISPLAY=:0. O si no lo has hecho, eso es lo que está siendo predeterminado. Esto indica al sistema local que use el socket de dominio UNIX para comunicarse con la pantalla. Desafortunadamente, Xmingen Windows no se configura ese socket de dominio UNIX, por lo que su sshreenvío X11 falla con este tipo de error:

$ export DISPLAY=:0
$ ssh -X remotehost xlogo
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0

La solución, al menos hasta donde Xmingllega, es bastante simple. Modifique la DISPLAYvariable para hacer referencia a un socket TCP de escucha en lugar de un socket de dominio UNIX.

$ export DISPLAY=localhost:0
$ ssh -X remotehost xlogo

Puede que tenga que adaptar su Xmingconfiguración para escuchar en el puerto TCP local 6000. Aquí es cómo empiezo Xming:

Xming.exe :0 -clipboard -multiwindow

Y aquí hay evidencia para confirmar que Xmingestá escuchando en el puerto tcp / 6000:

$ netstat -na | grep ':6000 .*LISTEN'
  TCP    0.0.0.0:6000           0.0.0.0:0              LISTENING
roaima
fuente
Gracias, tuve este problema exacto! No sabía que: 0 significa que la conexión se realiza a través de un socket. Siempre pensé que era solo una abreviatura de localhost: 0.
Andreas Raster el
Tuve el mismo problema con Bash para Ubuntu para Windows y Xming, ¡y esto lo resolvió! Solo tenía que configurar DISPLAY en localhost:0.
Ben Richards
¿Alguna idea de por qué DISPLAY=:0funciona bien en WSL + XMing para xeyes, pero no para ssh -X? ¿ ssh -XInterpreta $ DISPLAY de manera diferente a otros clientes X11 locales? ¿Otros clientes X11 retroceden automáticamente localhost:0pero ssh -Xno lo hacen?
Markus Kuhn el
En man Xél dice que el nombre de host vacío en DISPLAY =: 0 significa "Se elegirá el transporte local más eficiente". Entonces, ¿se puede ssh -Xusar un algoritmo diferente para hacer eso en comparación con decir xeyes?
Markus Kuhn el
@MarkusKuhn quizás WSL + Xming es diferente a Cygwin + Xming. Veo que ahora estoy usando DISPLAY=:0y lo ssh -Xreenvía felizmente.
roaima