¿Cómo soluciono un error de "no se puede abrir la pantalla" al abrir un programa X después de ssh'ing con el reenvío X11 habilitado?

Después de iniciar la aplicación X11 (XQuartz 2.3.6, xorg-server 1.4.2-apple56) en mi Mac (OS X 10.6.8), abrir un terminal en X11 y ejecutarlo xhost +, luego ssh -Ya mi Ubuntu 10.04 VM (ejecutándose en VMware Fusión). Cuando corro gedit .bashrc(por ejemplo), obtengo:

(gedit:9510): Gtk-WARNING **: cannot open display: 

set | grep DISPLAY no devuelve nada

Pero si entro ssh -Yen mi máquina Ubuntu 11.04, gedit .bashrcfunciona. echo $DISPLAYdevuelve "localhost: 10.0".

Lo intenté export DISPLAY=localhost:10.0mientras navegaba en mi VM y luego ejecutaba gedit .bashrc, pero obtengo:

(gedit:9625): Gtk-WARNING **: cannot open display: localhost:10.0

¿Qué podría ser diferente en la configuración de las dos máquinas Ubuntu diferentes que explicaría por qué una funciona y la otra no?

Actualización: según lo sugerido por Zoredache en el comentario a continuación, corrí sudo apt-get install xbase-clients, pero sigo teniendo el mismo problema.

Verifique sshd_config del servidor (normalmente /etc/ssh/sshd_config) y asegúrese de que la opción X11Forwarding esté habilitada con la línea

X11Forwarding yes

Si no se especifica X11Forwarding, el valor predeterminado es no en las máquinas Debian que tengo disponibles para verificar.

Desde xhost +: Cómo corregir el error "No se puede abrir la pantalla" al iniciar la GUI en el servidor remoto :

Respuesta : Puede corregir el error "no se puede abrir la pantalla" siguiendo el procedimiento xhost mencionado en este artículo.

Permitir que los clientes se conecten desde cualquier host usando xhost +

Ejecute el siguiente comando para deshabilitar el control de acceso, mediante el cual puede permitir que los clientes se conecten desde cualquier host.

$ xhost +

control de acceso deshabilitado, los clientes pueden conectarse desde cualquier host

Habilitar reenvío X11

Mientras hace ssh, use la opción -X para habilitar el reenvío X11.

$ ssh username@hostname -X

Habilite el reenvío X11 de confianza, utilizando la opción -Y,

$ ssh username@hostname -Y

Abrir aplicaciones GUI en ese host

Después de abrir la conexión ssh al host remoto como se explicó anteriormente, puede abrir cualquier aplicación GUI que la abrirá sin ningún problema.

Si aún recibe el error "no se puede abrir la pantalla", configure la variable DISPLAY como se muestra a continuación.

$ export DISPLAY='IP:0.0'

Nota: IP es la IP de la estación de trabajo local donde desea que se muestre la aplicación GUI.

También tuve este problema al iniciar sesión en una máquina virtual de Ubuntu desde Mac OS X; por alguna razón, no parece que me guste 'localhost' en la variable de pantalla. Configure la IP manualmente, como sugiere harrymc:

export DISPLAY="127.0.0.1:10.0"

Entonces los programas X11 deberían estar bien. No parece que deba ser necesario decirle al sistema operativo que localhost y 127.0.0.1 son equivalentes, pero al menos funciona.

Tuve este problema con mi servidor CentOS KVM, me faltaba el programa "xauth".

Si tiene este problema después de un tiempo cuando se ejecuta con -Xarg. o simplemente ForwardX11en / etc / ssh / ssh_config, luego ejecute $ ssh username@hostname -Y, para habilitar el reenvío X11 confiable , no sé la causa exacta, pero supongo que -Xalgunas características caducan después de un tiempo, probablemente para aumentar la seguridad.

Esto es lo que encontré en línea:

Si usa ssh -X remotemachine, la máquina remota se trata como un cliente no confiable. Entonces su cliente local envía un comando a la máquina remota y recibe la salida gráfica. Si su comando viola algunas configuraciones de seguridad, recibirá un error.

Pero si usa ssh -Y remotemachine, la máquina remota se trata como un cliente confiable. Esta última opción puede abrir problemas de seguridad. Debido a que otro cliente gráfico (X11) podría rastrear datos de la máquina remota (hacer capturas de pantalla, hacer keylogging y otras cosas desagradables) e incluso es posible alterar esos datos.

Si desea saber más sobre esas cosas, le sugiero que lea la página de manual de Xsecurity o la especificación de la extensión X Security. Además, puede verificar las opciones ForwardX11 y ForwardX11Trusted en su / etc / ssh / ssh_config.

fuentes:

• ¿Cuál es la diferencia entre ssh -Y y ssh -X?
• advertencia de cygwin / X: no se pudo abrir la pantalla X

Recién probado en mi Mac, otros sistemas podrían estar bien :

1. Permitir que los clientes se conecten desde cualquier host usando xhost +

   $ xhost +

2. Debe tener un entorno que admita la pantalla X11

   [Sistema Mac] Instale X11 para Mac https://www.xquartz.org/

3. Debe dejar que su servidor ssh reenvíe la pantalla x11

   actualizar /etc/ssh/sshd_configy configurar X11Forwarding yes, luego reinicie su servidor ssh

4. Debe dejar que su sesión ssh reenvíe x11 con el -Xparámetro

   $ ssh -X usuario @ ip

5. ¿Cómo abrir la aplicación X11 en PyCharm?

   • abra una sesión ssh que admita la pantalla X11 (recuerde mantener esta sesión)
   • correr echo $DISPLAYen esa sesión ssh
   • Establecer DISPLAYvariable de entorno para su PyCharm

Cuando ejecute UXTERM o XTERM solo emita

export $DISPLAY 

La variable estará allí. Luego solo configúrelo y expórtelo.

Tuve que poner /etc/ssh/sshd_configlo siguiente:

X11UseLocalhost no

En lugar de configurarlo "sí". Es extraño si el valor predeterminado es "NO" Usuarios que usan masilla con XMing en Windows. Yo uso SSH directo sobre Fedora. Ocasionalmente comenzaría a darnos

error can't open display localhost

El reinicio del servidor generalmente lo solucionaría, pero esto es estúpido. Hice lo anterior, reinició el servicio sshden el servidor y presto nuevas conexiones funcionando bien nuevamente.

También tuve este problema con Solaris 10 y descubrí que el oyente no estaba configurado.

svccfg –s /application/x11/x11-server listprop options/tcp_listen
svccfg –s /application/x11/x11-server setprop  options/tcp_listen = true

En CentOS 6.5, de repente perdí el acceso remoto a los programas X después de jugar con / etc / hosts. El mismo síntoma de la variable $ DISPLAY vacía (no hay ayuda para configurarla / exportarla manualmente).

La entrada 127.0.0.1 que apunta al nombre de host real es necesaria; de hecho, el orden también parece ser relevante (pon el último y no funcionará ...)

[root@poseidon /etc]$ cat hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1     localhost6.localdomain6 localhost6
127.0.0.1 poseidon.mycampus.edu poseidon
1XX.XXX.XXX.208 poseidon.mycampus.edu poseidon

Después de arreglar esto, xeyes, xclock y otros juguetes de prueba X están funcionando nuevamente, por lo tanto, mi virt-manager necesario también está en línea.

Acabo de encontrar un buen inconveniente en mi configuración que impidió el reenvío x: mi firewall estaba bloqueando todas las conexiones desde localhost, evitando así que se alcanzara el túnel

Si está usando Konsole, simplemente cambie a otro emulador de terminal como Xfce Terminal e intente nuevamente usar root.

terminal abierta $ ssh username @ hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY = "127.0.0.1:10.0" todo debería funcionar.

Esta configuración me funciona:

Local (Cygwin de 64 bits en Windows 10) DISPLAY=:0

Servidor (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

Estas configuraciones se encontraron haciendo clic en "X menú de aplicaciones en: 0" en la barra de tareas y seleccionando Herramientas del sistema> Terminal

Después de mucha frustración, descubrí que la entrada para el nombre de host del servidor en su archivo / etc / host era incorrecta.