¿Cómo puedo corregir 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?

De xhost+ : Cómo arreglar el error “No se puede abrir la pantalla” mientras se lanza la GUI en el servidor remoto :

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

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

Ejecutar el siguiente comando para desactivar el control de acceso, por el cual puede permitir que los clientes se conecten desde cualquier host.

$ xhost +

control de acceso desactivado, 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

Habilitar reenvío X11 de confianza, usando 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 ha explicado anteriormente, puede abrir cualquier aplicación GUI que la abra sin ningún problema.

Si sigue obteniendo el error “cannot open display”, 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 quiere que se muestre la aplicación GUI.

Comprueba el sshd_config del servidor (normalmente /etc/ssh/sshd_config), y asegúrate de que la opción X11Forwarding está activada con la línea

X11Forwarding yes

Si no se especifica X11Forwarding, el valor por defecto es no en las máquinas de Debian que tengo disponibles para comprobar.

También he tenido este problema al acceder a un VM de Ubuntu desde Mac OS X… por alguna razón no parece que le guste el “localhost” en la variable de visualización. Así que configura 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 sea necesario decirle al SO que localhost y 127.0.0.1 son equivalentes, pero funciona, al menos.

Tuve un problema con mi servidor KVM CentOS, me faltaba el programa “xauth”.

Si tienes este problema después de algún tiempo cuando corras con -X arg. o sólo ForwardX11 en /etc/ssh/ssh_config, entonces ejecuta $ ssh username@hostname -Y, para habilitar el redireccionamiento X11 de confianza, no sé la causa exacta pero supongo que con -X algunas características expiran después de algún tiempo, probablemente para aumentar la seguridad.

Esto es lo que encontré en línea :

Si usas ssh -X remotemachine la máquina remota es tratada como un cliente no confiable. Así que tu cliente local envía un comando a la máquina remota y recibe la salida gráfica. Si tu comando viola algunas configuraciones de seguridad recibirás un error en su lugar.

Pero si usas ssh -Y remotemachine la máquina remota es tratada como un cliente de confianza. Esta última opción puede abrir problemas de seguridad. Debido a que otros clientes gráficos (X11) podrían oler datos de la máquina remota (hacer capturas de pantalla, hacer keylogging y otras cosas desagradables) e incluso es posible alterar esos datos.

Si quieres saber más sobre esas cosas te sugiero que leas la página de manual de Xsecurity o la especificación de la extensión X Security. Además puedes comprobar las opciones ForwardX11 y ForwardX11 Confiable en tu /etc/ssh/ssh_config.

fuentes:

• cual es la diferencia entre ssh -Y y ssh -X
• advertencia de cygwin/X: no pudo abrir la pantalla X

Acabo de probar en mi Mac, otros sistemas podrían estar bien :

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

$ xhost +

1. Debe tener un entorno que soporte la visualización de X11

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

1. Deberías dejar que tu ssh-server reenvíe x11 display

update /etc/ssh/sshd_config y configurar X11Forwarding yes, y luego reiniciar tu servidor ssh

1. Deberías dejar que tu sesión ssh reenvíe x11 display con el parámetro -X

$ ssh -X user@ip

• abre una sesión ssh que soporte el display X11 (recuerda mantener esta sesión)
• ejecuta echo $DISPLAY en esa sesión ssh
• establece la variable de entorno DISPLAY para tu PyCharm

Tuve que poner en /etc/ssh/sshd_config lo siguiente:

X11UseLocalhost no

en lugar de ponerlo en “sí”. Es extraño si el valor por defecto es “NO” Los usuarios que usan masilla con XMing en Windows. Yo uso ssh directo sobre Fedora. De vez en cuando empezaría a darnos

error can't open display localhost

El reinicio del servidor normalmente lo arreglaría pero esto es estúpido. Hice lo anterior, reinicié el servicio sshd en el servidor y presto las nuevas conexiones funcionando bien de nuevo.

Cuando se ejecuta UXTERM o XTERM, sólo hay que emitir

export $DISPLAY

La variable estará allí. Entonces sólo hay que configurarla y exportarla.

Esta configuración funciona para mí:

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

Servidor (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

Estas configuraciones fueron encontradas haciendo clic en “X menú de aplicaciones en :0” en la barra de tareas y seleccionando Herramientas del Sistema > Terminal

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

Si por casualidad estás usando Konsole, simplemente cambia a otro emulador de terminales como Xfce Terminal e inténtalo de nuevo usando root.

En CentOS 6.5, de repente perdí el acceso a los programas X remotos después de haberme metido 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 del host actual es necesaria; de hecho el orden parece ser también relevante (poner el último & 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, los xeyes, xclock y otros juguetes de prueba X están funcionando de nuevo, por lo tanto mi necesario virt-manager también está de nuevo en línea.

Acabo de encontrar un buen hipo en mi configuración que impidió el reenvío X: Mi cortafuegos bloqueaba todas las conexiones del host local, evitando así que se llegara al túnel.

abrir terminal $ ssh nombre de usuario@nombre de host -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

exportar DISPLAY=“127.0.0.1:10.0” todo debería funcionar.