Reenvío X11 y archivo .Xauthority

Reenvío X11 y archivo .Xauthority

He buscado una respuesta a esta pregunta de vez en cuando durante las últimas semanas, pero ninguna de las soluciones que he visto ha funcionado para mí. Intenté eliminar el archivo .Xauthority en ambas ubicaciones. Utilizo Cygwin X para acceder a otra computadora. Recientemente, el reenvío X11 no ha funcionado. Después de iniciar el servidor X en mi máquina local:

[local]$ export DISPLAY=0.0    
[local]$ ssh -XY user@remotelocation
Warning: No xauth data; using fake authentication data for X11 forwarding.

No estoy seguro si esto es útil, pero:

[remote]$ xauth list
location/unix:10 MIT-MAGIC-COOKIE-1 304eb389beb66bf44ae6bc1821bdf472

Finalmente, el problema ocurre aquí:

[remote]$ gedit file &
X11 connection refused because of wrong authentication.

Siempre recibí la advertencia "sin datos xauth; usando autenticación falsa", pero recientemente, como resultado, la conexión X11 fue rechazada. ¿Tienes alguna sugerencia?

Respuesta1

Intenté eliminar el .Xauthorityarchivo en ambas ubicaciones.

Quizás algo salió mal antes de eso, pero ciertamente no tendrás éxito después de esto. Si encontró este consejo en alguna parte y no se refería a alguna circunstancia extremadamente inusual que no se aplica a usted, incluya esa fuente en la lista negra. Restaure el .Xauthorityarchivo en el cliente.

Si ha perdido el .Xauthorityarchivo, es posible que pueda restaurarlo desde un proceso en ejecución o desde un archivo temporal. No tengo idea de cómo hacerlo con Cygwin. La forma sencilla que funcionará en todas partes es salir del servidor X e iniciar uno nuevo.

Si recibe el mensaje “no hay datos de autenticación; usando autenticación falsa”, entonces las aplicaciones remotas no podrán mostrarse en su servidor local a menos que esté configurado con la seguridad desactivada. Sin la seguridad de xauth, cualquiera puede espiar su sesión X e inyectar información si puede acceder al servidor X; Dependiendo de la configuración, es posible que necesiten ser usuarios locales (en cuyo caso no es tan malo en un sistema operativo de un solo usuario) o puede ser suficiente que puedan abrir una conexión TCP a su máquina (es decir, son en su red local, que podría ser cualquiera si, por ejemplo, utiliza wifi público). Si solía funcionar y ya no funciona, puede deberse a que recientemente se solucionó algún control de seguridad faltante.

Una vez que tenga un .Xauthorityarchivo válido, abra un shell y verifique que pueda ejecutar aplicaciones locales como gedit. Desde ese mismo shell, ejecute ssh -X user@remotelocatione intente ejecutar una aplicación X. O eso funcionará o recibirás mensajes de error; Léelos y cópialos y pégalos si pides ayuda. Si no funciona, ejecute ssh -vv -X user@remotelocation; el resultado de depuración adicional brindará información sobre por qué no funciona.

Asegúrese de que el servidor permita conexiones X remotas. Con OpenSSH, el archivo /etc/sshd_config(o /etc/ssh/sshd_configalguna otra ubicación dependiendo de la distribución) debe contener X11Forwarding yes.

información relacionada