¿Cómo depuro "la conexión X11 rechazada debido a una autenticación incorrecta"

Tengo un problema con el reenvío de X a través de SSH. He luchado durante años, pero parece que nadie puede ayudar.

Ahora estoy tomando un tacto diferente. ¿Me gustaría saber cómo depurar los errores?

¿Qué registros debo buscar, qué marcas adicionales debo establecer (-v, etc.) y qué debo buscar?

Edición adicional:

Si inicio sesión en Putty en el servidor e intento xeyes, obtengo:

Proxy PuTTY X11: intento de protocolo de autorización incorrecto Error: no se puede abrir la pantalla: localhost: 10.0

Si xauth generate $DISPLAYme sale:

Proxy PuTTY X11: protocolo de autorización incorrecto intentoxauth: (argv): 1: no se puede abrir la pantalla "localhost: 10.0".

Mi solución paso a paso:

1) inicie sesión con la opción -X raíz de inicio de sesión de host remoto

$ ssh -X root@192.168.1.39

2) compruebe si existe un archivo .Xauthority

[root @ localhost ~] # ls -al
[root @ localhost ~] # vim .Xauthority

3) copie el archivo .Xauthority al directorio del otro usuario

[root @ localhost ~] # cp .Xauthority / home / oracle /
cp: sobrescribir `/home/oracle/.Xauthority '? y

4) establecer permisos para este archivo

[root @ localhost ~] # oráculo chown: oinstall .Xauthority
[root @ localhost ~] # chmod 0600 .Xautoridad

5) iniciar sesión usuario de Oracle

[root @ localhost ~] # su - oráculo

6) configuración de visualización en localhost: 10.0

[oracle @ localhost ~] $ echo $ DISPLAY
localhost: 10.0
[oráculo @ localhost ~] $ ls -al

7) enumera las cookies xauth existentes

[oracle @ localhost ~] $ xauth lista
localhost.localdomain / unix: 11 MIT-MAGIC-COOKIE-1 310f1b02c1080e73059391c193a1881b
localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb759

8) agregando

[oracle @ localhost ~] $ xauth add localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75

9) prueba

[oráculo @ localhost ~] $ xclock

Espero que les sirva! @wcaraza

Asegúrese de que el servidor SSH tenga xauthinstalada la herramienta y que su ~/.Xauthorityarchivo se pueda escribir. (Inexistente también está bien, siempre que xauthpueda crearlo).

Compruebe si los datos de xauth se están actualizando:

server$ xauth list

Intente agregar manualmente datos ficticios de xauth (nuevamente, en el servidor SSH) y vea si xauthtiene algún problema (por ejemplo, no poder crear el archivo de bloqueo o modificar el archivo Xauthority):

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

Si es necesario, vuelva a ejecutar debajo strace.

Ejecute el servicio SSH en modo de depuración, configurando LogLevel DEBUG2en la configuración del servidor ( /etc/ssh/sshd_config), o iniciando sshd en modo de depuración directamente:

server$ sshd -rddp 12234

(En este ejemplo, 12234es el puerto SSH temporal al que necesita conectarse. Cualquier puerto libre servirá).

Está funcionando, está funcionando. jaja.

FINALMENTE.

Después de descubrir que no era el sistema, al agregar un usuario de prueba (cuyo reenvío x funcionó "de fábrica"), pensé en comenzar a copiar los archivos de inicio .bash * para virginizar al usuario "roto".

Ninguno de los archivos era diferente, por lo que luego eliminé el directorio .ssh de usuarios. Cuando entré, gimió sobre "El servidor rechazó nuestra clave", pero pude iniciar sesión con una contraseña. Una vez que inicie sesión, podría x reenviar perfectamente.

Ahora intentaré configurar la clave nuevamente y ver si puedo hacer que funcione también. Entonces volverá a la normalidad.

Una cosa más que puede causar este problema es la existencia de un ~/.ssh/rcarchivo en el servidor, la máquina a la que se está conectando. Elimínelo (o cámbiele el nombre) para resolver el problema.

rm ~/.Xauth* y luego reconectarte.

Esto funciona para mi. Para más detalles