☰

¿Cómo depuro "Conexión X11 rechazada debido a una autenticación incorrecta"?

tag-icon • tag-icon ssh logging debug x11-forwarding
¿Cómo depuro "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 ayudarme.

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

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

Edición adicional:

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

Proxy PuTTY X11: se intentó un protocolo de autorización incorrectoError: no se puede abrir la pantalla: localhost:10.0

Si xauth generate $DISPLAYobtengo:

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

Respuesta1

Mi solución paso a paso:

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

$ssh -X[correo electrónico protegido]

2) comprobar si existe el archivo .Xauthority

[raíz@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 ~]# chown oracle:oinstall .Xauthority
[root@localhost ~]# chmod 0600 .Xautoridad

5) iniciar sesión como usuario de Oracle

[raíz@localhost ~]# su - oracle

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

[oracle@localhost ~]$ eco $DISPLAY
servidor local: 10.0
[oracle@localhost ~]$ ls -al

7) enumera las cookies xauth existentes

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

8) agregando

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

9) prueba

[oracle@localhost ~]$ xreloj

Espero que les sirva! @wcaraza

Respuesta2

Asegúrese de que el servidor SSH tenga la xauthherramienta instalada y que ~/.Xauthorityse pueda escribir en su archivo. (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 ejecutarlo en strace.

Ejecute el servicio SSH en modo de depuración, estableciendo 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á).

Respuesta3

Está funcionando, está funcionando. ja ja.

FINALMENTE.

Después de descubrir que no era el sistema, al agregar un usuario de prueba (que el 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, así que a continuación eliminé el directorio .ssh de los usuarios. Cuando entré por ssh, se quejó de "El servidor rechazó nuestra clave", pero pude iniciar sesión con la contraseña. Una vez conectado, pude avanzar perfectamente.

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

Respuesta4

rm ~/.Xauth*y luego volver a conectar.

Esto funciona para mí. Para másdetalles

información relacionada