SSH X11 no funciona

Tenemos la mejor solución que descubrimos en todo internet. Nosotros esperamos que te resulte de ayuda y si puedes aportar algo que nos pueda ayudar a crecer siente la libertad de hacerlo..

Solución:

Solución 1:

La razón por la que el reenvío ssh X no funcionaba era porque tengo un /etc/ssh/sshrc archivo de configuración.

El final de sshd(8) estados de la página man:

Si ~/.ssh/rc existe, lo ejecuta; si no /etc/ssh/sshrc existe, lo ejecuta; de lo contrario, ejecuta xauth

Entonces agrego los siguientes comandos a /etc/ssh/sshrc (también de la página de manual de sshd) en el lado del servidor:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

¡Y funciona!

Solucion 2:

Siempre que tenga problemas con ssh, lo primero que debe hacer es ejecutar el cliente con el -v opción para proporcionar esa salida para que otros la inspeccionen:

ssh -v [email protected]

Voy a suponer que el problema está en su sistema local. ¿Cómo invocas el comando ssh? ¿Lo está ejecutando manualmente en un shell? ¿O se está ejecutando como parte de un script? En cualquier caso, querrá asegurarse de que su sistema local tenga la DISPLAY entorno configurado correctamente. También debe configurarse correctamente en el lado remoto, pero ese valor Será diferente en el lado remoto que en el lado local.

Por lo que escribió, parece que se está configurando correctamente en el host remoto (y, por extensión, ssh está configurando correctamente el reenvío X11). En el sistema remoto tienes:

$ echo $DISPLAY
localhost:10.0

¿Qué está mostrando eso en el lado local? Eso debería ser fácil de verificar si está en un shell tanto al hacer eco del valor como al iniciar una aplicación X desde ese shell … siempre puede usar el venerable xeyes para ese tipo de pruebas, ¡por supuesto! 🙂

Por otro lado, si está invocando el comando ssh desde un script o adjunto a una tecla de acceso rápido, es posible que no herede el entorno que espera, por lo que DISPLAY Es posible que la variable de entorno en el lado local no esté configurada en absoluto.

Además, dado que parece que has estado jugando con tu .Xauthority archivo, es posible que desee eliminarlo por completo, luego cierre la sesión de X y vuelva a iniciarla para que se vuelva a crear automáticamente. Rara vez es necesario ensuciar con su .Xauthority, por lo que intentarlo es probablemente una medida desesperada que no ayudará.

Lo que debería ver en el lado local es:

$ echo $DISPLAY
:0.0

En un sistema configurado correctamente, si abre un shell, no debería necesitar configurarlo a mano, debería heredarse del entorno que inició su shell. Sin embargo, he visto configuraciones de administrador de ventanas / teclas de acceso rápido que no manejan correctamente la herencia de variables de entorno. Si tiene un sistema Linux en ejecución gnome-session o kde-session que usa para iniciar sus shells o scripts, entonces las variables de entorno de su sesión X deben configurarse correctamente como se describe en la documentación de Ubuntu sobre la herencia de las variables de entorno:

Cuando un proceso padre crea un proceso hijo, por ejemplo, cuando ejecutamos el comando “gedit” desde la terminal y “bash” (el proceso padre) crea “gedit” (el proceso hijo), el proceso hijo hereda todas las variables de entorno y valores que tenía el proceso padre.

…

Nota: en el entorno de escritorio gráfico de Gnome, gnome-session es el proceso principal de todos los procesos que se ejecutan en el escritorio. Este hecho (junto con el principio de herencia) es el key a nuestra capacidad de influir poderosamente en el funcionamiento de nuestro escritorio con variables de entorno. El proceso equivalente en KDE es kde-session.

ACTUALIZADO

Gracias por publicar el resultado de ssh -vvv. En este caso, la verbosidad extra de -vvv versus solo -v es útil. La salida de depuración me dice que el reenvío X11 se está configurando correctamente:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Pero el :0 en la primera línea me lleva a creer que todavía hay un error de configuración en el lado local en la forma en que invoca ssh. En muchos sistemas, el valor predeterminado para DISPLAY es :0.0, no :0. ¿Estás estableciendo de alguna manera el valor de DISPLAY manualmente usted mismo antes de invocar el comando ssh?

En este punto, sería útil obtener más información sobre su sistema local y cómo está invocando el comando ssh.

• Proporcione su distribución de Linux y el número de versión.
• ¿Está utilizando un entorno GNOME o KDE predeterminado para X o algo más que haya personalizado usted mismo?
• ¿Está invocando ssh directamente en una línea de comando desde una ventana de terminal?
• ¿Qué terminal estás usando? xterm, gnome-terminal o?
• ¿Cómo inició la ejecución de la terminal en el entorno X? ¿De un menú? Tecla de acceso directo? o ?
• Puedes correr xeyes desde la misma ventana de terminal donde el ssh -X falla?
• ¿Está invocando el comando ssh como el mismo usuario con el que inició sesión en la sesión X?

Este último elemento es importante. Si está ejecutando ssh como otro usuario (por ejemplo, si abrió una ventana de terminal raíz en lugar de una ventana de terminal de usuario), encontrará este problema incluso si está configurando explícitamente DISPLAY=:0 ya que no tiene permisos para conectarse al servidor X de forma predeterminada como otro usuario (¡incluso como root!)

Puedes añadir valor a nuestra información dando tu veteranía en las ilustraciones.

---

---

Utiliza Nuestro Buscador