¿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?


112

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.


2
¿El cuadro Ubuntu 10.04 tiene instaladas las herramientas adecuadas para X11? Instale xbase-clients, si aún no está instalado.
Zoredache

Lo instalé pero todavía tengo el mismo problema. (Ver arriba.)
Daryl Spitzer

3
Tal vez intente pasar la opción -vv a ssh cuando se conecte, esto imprime mensajes de depuración detallados, debería ver varios comentarios sobre el reenvío X11 mientras se conecta.
Zoredache

1
@jcrawfordor Ha comprobado el X11Forwardingen el ubuntu, y que ha xbase-clientsinstalado y que puede iniciar Xapps en el mac en el terminal desde el que está haciendo la conexión ssh. (Compruebe que $DISPLAYestá configurado en el terminal ejecuta ssh desde .
Manwë

1
En mi caso, solo era cuestión de actualizar la versión XQuartz de MacOS
Waruna Ranasinghe

Respuestas:


48

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.


44
Después de configurar otra máquina virtual Ubuntu, descubrí que necesito instalar xbase-clients y habilitar X11Forwarding. Actualice su respuesta para incluir ambos y lo aceptaré.
Daryl Spitzer

1
Interesante. Al menos en la nueva instalación de 10.04 que hice esta mañana, X11Forwarding estaba habilitado por defecto. Los chicos de Ubuntu deben estar jugando con los valores predeterminados nuevamente.
Zoredache

29
@DerfK, en mi sistema "X11Forwarding yes" ya estaba allí, todavía recibo un error, (gedit: 8381): Gtk-WARNING **: no se puede abrir la pantalla: en tales casos
AJ

1
En Debian puede que tenga que instalar el paquete xauth, luego vuelva a iniciar sesión.
comte

$ ssh username @ hostname -Y esto funcionó para mí
MarcoZen

61

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.


12
+1 para la Nota que IP = es la IP de la estación de trabajo local donde desea obtener la GUI
PCoder

3
Para aquellos que tienen problemas similares en OS X, también asegúrese de tener XQuartz instalado, de lo contrario, ninguna de estas soluciones ayuda. (La pregunta de OP muestra que tiene XQuartz, así que esta es más una nota al margen para aquellos que tienen problemas similares a los que yo tenía)
Dolan Antenucci

3
Tenga en cuenta que la ejecución xhost +es muy insegura y no debe usarse. Como mencionó Stefan Rogin, el atacante puede conectarse desde su host a su XSession, leer todo lo que escribe o incluso alterar la pantalla que ve.
jirislav

el último lo export Display=IP:0.0hizo por mí
javadba

18

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.


Esto funcionó para mí. ¿Alguna idea de por qué localhost no funcionaba?
Alex

2
¡BINGO! He estado atrapado por ese problema por algún tiempo ... Me conecté por SSH y no pude iniciar programas Gtk (sin embargo, X11 simple, como "xeyes", funcionó). PANTALLA fue correcta. En realidad, la resolución de "localhost" no lo fue! Si configuro manualmente DISPLAY = 127.0.0.1: 10.0, o DISPLAY = :: 1: 10.0 funciona. La edición de / etc / hosts parece no tener efecto; y DNS está configurado correctamente (informe de correcty "dig localhost" tanto 127.0.0.1 como :: 1) Entonces, parece ser un error en lo que sea la resolución DNS para conexiones X11 en Gtk (gtk? gdk? glib? otro?).
Pablo Saratxaga

1
En una instalación de Debian para Beagle Bone Black, / etc / host no fue configurado para ser leído por nadie más que root. Esto causó los síntomas reportados aquí. Hecho / etc / hosts legible por todos, y funcionó bien.
Daniel

13

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


1
Esto me ayudó en mi instalación mínima de Debian, ¡muchas gracias!
binOr

9

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:


6

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

1
¿Por qué es diferente o por qué debería preferirse a cualquiera de las otras respuestas? Por favor explique si puede con una simple edición . ¡¡Puedes hacerlo!!
Pimp Juice IT

@ McDonald's Gracias, actualizado con más detalles.
Color

4

Cuando ejecute UXTERM o XTERM solo emita

export $DISPLAY 

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


4

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.


2

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

1

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.


1

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


1

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


1

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.


Gracias. Funciona para mi caso especial cuando DISPLAY='localhost:10.0'no funciona.
xpt

1

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


0

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.