SSH X11 no funciona

Tengo una computadora en casa y en el trabajo, la computadora en casa tiene una dirección IP estática.

Si ssh desde la computadora de mi trabajo a la computadora de mi casa, la conexión ssh funciona pero no se muestran las aplicaciones X11.

En mi /etc/ssh/sshd_configen casa:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

En el trabajo probé los siguientes comandos:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Mi /etc/ssh/ssh_configen el trabajo

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Mi ~/.ssh/configen el trabajo

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Mi ~/.Xauthorityen el trabajo

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Mi ~/.Xauthorityen casa

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Pero no funciona

Después de hacer una conexión ssh a casa:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Lo uso iptablesen casa, pero he permitido el puerto 22. Según lo que he leído, eso es todo lo que necesito.

UPD Con-vvv

...
debug2: inicio de devolución de llamada
debug2: x11_get_proto: / usr / bin / xauth list: 0 2> / dev / null
debug1: solicitud de reenvío de X11 con falsificación de autenticación.
debug2: canal 1: solicitud x11-req confirmar 1
debug2: client_session2_setup: id 1
debug2: fd 3 configurando TCP_NODELAY
debug2: canal 1: solicitud pty-req confirmar 1
...

Cuando intente iniciar kate:

debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: solicitud de 127.0.0.1 55486
debug2: fd 8 configurando O_NONBLOCK
debug3: fd 8 es O_NONBLOCK
debug1: canal 2: nuevo [x11]
debug1: confirmar x11
debug2: la conexión X11 utiliza un protocolo de autenticación diferente.
Conexión X11 rechazada debido a una autenticación incorrecta.
debug2: X11 rechazó 2 i0 / o0
debug2: canal 2: lectura fallida
debug2: canal 2: close_read
debug2: canal 2: entrada abierta -> drenaje
debug2: canal 2: ibuf vacío
debug2: canal 2: enviar eof
debug2: canal 2: drenaje de entrada -> cerrado
debug2: canal 2: error de escritura
debug2: canal 2: close_write
debug2: canal 2: salida abierta -> cerrada
debug2: X11 cerrado 2 i3 / o3
debug2: canal 2: enviar cerrar
debug2: canal 2: cierre de rcvd
debug2: canal 2: está muerto
debug2: canal 2: recolección de basura
debug1: canal 2: gratis: x11, nchannels 3
debug3: canal 2: estado: las siguientes conexiones están abiertas:
  # 1 sesión de cliente (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Lo mismo que arriba se repite aproximadamente 7 veces

Kate: no se puede conectar al servidor X localhost: 10.0

UPD2 Proporcione su distribución de Linux y número de versión.
¿Está utilizando un entorno predeterminado de GNOME o KDE para X o algo más que haya personalizado?

azat: ~ $ kded4 -version
Qt: 4.7.4
Plataforma de desarrollo de KDE: 4.6.5 (4.6.5)
KDE Daemon: $ Id $

¿Invoca ssh directamente en una línea de comando desde una ventana de terminal?
¿Qué terminal estás usando? xterm, gnome-terminal o?
¿Cómo comenzó a ejecutar el terminal en el entorno X? De un menú? Hotkey? o

Desde el emulador de terminal `yakuake`
Presione manualmente `Ctrl + N` y escriba los comandos

¿Puedes ejecutar xeyes desde la misma ventana de terminal donde falla el ssh -X?

`xeyes` - no está instalado
Pero `kate` u otra aplicación kde se está ejecutando

¿Invoca el comando ssh como el mismo usuario con el que inició sesión en la sesión X?
From the same user

UPD3

También descargo sshfuentes, y debug2()escribo por qué informa que la versión es diferente.
Ve algunas cookies, y una de ellas está vacía, otra esMIT-MAGIC-COOKIE-1

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

El final de la sshd(8)página del manual dice:

Si ~/.ssh/rcexiste, lo ejecuta; si no /etc/ssh/sshrcexiste, lo ejecuta; de lo contrario se ejecuta xauth

Entonces agrego los siguientes comandos a /etc/ssh/sshrc(también desde 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!

Cada vez que tenga problemas con ssh, lo primero que debe hacer es ejecutar el cliente con la -vopción de proporcionar esa salida para que otros la inspeccionen:

ssh -v user@somewhere

Voy a adivinar que el problema está en su sistema local. ¿Cómo estás invocando el comando ssh? ¿Lo estás 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 el DISPLAYentorno 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.

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

$ echo $DISPLAY
localhost:10.0

¿Qué muestra eso en el lado local? Eso debería ser fácil de verificar si estás en un shell tanto haciendo eco del valor como iniciando una aplicación X desde ese shell ... ¡siempre puedes usar el venerable xeyespara ese tipo de pruebas, por supuesto! :)

Por otro lado, si está invocando el comando ssh desde un script o adjuntado a una tecla de acceso rápido, es posible que no herede el entorno que espera, por lo que es posible que DISPLAYla variable de entorno en el lado local no se configure en absoluto.

Además, dado que parece que ha estado jugando con su .Xauthorityarchivo, es posible que desee eliminarlo por completo, luego cierre la sesión de X y vuelva a iniciarla para que lo vuelva a crear automáticamente. Rara vez hay una necesidad de fastidiarlo .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, sino que 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-sessiono kde-sessionque utiliza 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 el 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 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 la clave de 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 adicional de -vvvversus solo -ves ú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 :0en 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 estás invocando ssh. En muchos sistemas, el valor predeterminado para DISPLAYes :0.0, no :0. ¿De alguna manera está configurando el valor de DISPLAYusted mismo antes de invocar el comando ssh?

Sería útil obtener más información sobre su sistema local y cómo está invocando el comando ssh en este momento.

• Proporcione su distribución de Linux y número de versión.
• ¿Está utilizando un entorno predeterminado de GNOME o KDE para X o algo más que haya personalizado?
• ¿Invoca ssh directamente en una línea de comando desde una ventana de terminal?
• ¿Qué terminal estás usando? xterm, gnome-terminal o?
• ¿Cómo comenzó a ejecutar el terminal en el entorno X? De un menú? Hotkey? o
• ¿Se puede ejecutar xeyesdesde la misma ventana de terminal donde ssh -Xfalla?
• ¿Invoca el comando ssh como el mismo usuario con el que inició sesión en la sesión X?

Este último artículo 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), entonces encontrará este problema incluso si está configurando explícitamente DISPLAY=:0ya que no tiene permisos para conectarse al servidor X por defecto como otro usuario (¡incluso como root!)

Sus configuraciones parecen estar bien, pero intente "ssh -X home" como sugirió Agemen.

Además, si todo lo demás falla, intente esto:

Después de que ssh a su máquina doméstica desde el trabajo, en el tipo "hogar":

xauth list

Luego, en "trabajo", escriba

xauth

Lo que te dará un mensaje "xauth>". Desde aquí, escriba "agregar", luego copie y pegue el resultado de la "lista xauth", una línea a la vez (cada línea precedida por "agregar"). Por ejemplo:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Haznos saber.

No entiendo claramente si desea mostrar sus aplicaciones remotas en su pantalla local ( work), o si desea mostrarlas en el sistema remoto ( home).

En el primer caso, creo que ssh -X hostdebería ser suficiente, sin necesidad de usar xhost.

En el segundo caso, el sistema donde necesita usar xhost es home, y no es suficiente, también necesita exportar la variable de visualización.

xhost +work
export DISPLAY=:0.0

No estoy totalmente seguro de lo que quiere hacer ... y como no sé qué diferencias existen entre su sistema y el mío, por un lado, y la configuración exacta necesaria para su caso, por otro lado (como No soy especialista ^ _ ^). Espero que te ayude de alguna manera, ya que estas configuraciones también me han funcionado.