2014-09-03 10:44:44 +0000 2014-09-03 10:44:44 +0000
30
30

xauth no crea el archivo .Xauthority

Cuando hago ssh en un sistema Linux Mint 17 sin cabeza, no crea actualización / crea un archivo .Xauthority.

Además, cuando ejecuto xauth obtengo la respuesta: 

marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>exit
marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>

No crea el archivo.

EDITAR:

Cuando me conecto al monitor, y luego me conecto localmente, se crea el archivo pero cuando intento añadir una entrada (porque mi SSH no lo hace por mí): 

marty@N40L ~ $ xauth list
N40L/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
marty@N40L ~ $ ls -d .X*
-rw------- 1 marty marty 115 Sep 3 12:03 .Xauthority
marty@N40L ~ $ xauth generate $DISPLAY .
PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1: unable to open display "localhost:10.0".

Por cierto, al hacer un netstat --listen se muestra la escucha del puerto: 

tcp 0 0 localhost:6010 *:* LISTEN

AGH, más información. Me desconecté de la sesión X en el servidor, y ahora el archivo .Xauthority ha desaparecido. Parece que el archivo sólo está ahí cuando se conecta localmente. ¿Alguien puede decirme por qué, o cómo puedo arreglar esto?

NUEVO DESARROLLO:

Creé un usuario virgen en el sistema llamado “test”. Luego me conecté, y sin ningún otro comando, ejecuté “xeyes”. ¡Lo cual funcionó! Así que es SOLO el usuario “marty” el que no puede hacer “xforward”. ¿Cómo copio la configuración de “test” a “marty”?
Fuente

Respuestas (6)

35
35
35
2015-07-16 04:15:44 +0000

Sólo para informar, tuve un problema similar. Pero en mi caso sólo sigo esos pasos :

Sigue estos pasos para crear un archivo $HOME/.Xauthority.

Entra como usuario y confirma que estás en el directorio principal del usuario. 

# Rename the existing .Xauthority file by running the following command
mv .Xauthority old.Xauthority 

# xauth with complain unless ~/.Xauthority exists
touch ~/.Xauthority

# only this one key is needed for X11 over SSH 
xauth generate :0 . trusted 

# generate our own key, xauth requires 128 bit hex encoding
xauth add ${HOST}:0 . $(xxd -l 16 -p /dev/urandom)

# To view a listing of the .Xauthority file, enter the following 
xauth list

Después de eso no hay más problemas con el archivo .Xauthority desde entonces.

Gracias y créditos a srinivasan .
Fuente
4
4
4
2018-02-20 15:30:16 +0000

Sólo para complementar las excelentes toneladas ’s respuesta .

Una vez tuve exactamente el mismo problema porque mi directorio de inicio se había llenado al 100%. Al conectarse, ssh creó un ~/.Xauthority vacío y no pudo escribir ninguna entrada en él (de modo que xauth list siempre había producido una salida vacía).

Por lo tanto, sugiero que siempre se compruebe el espacio libre (por ejemplo: df -h) y se verifique que xauth generate y xauth add han tenido algún efecto (xauth list).
Fuente
1
1
1
2015-05-20 14:06:07 +0000

Quitar el directorio .ssh hizo que el reenvío de X funcionara para mí.

A través del proceso de eliminación, encontré un archivo en ~/.ssh que se llamaba “rc”, y contenía: 

echo "Wecome to $(hostname), $(whoami)"

Nunca creé esto, y no tengo ni idea de dónde vino. Quitarlo arregló el problema, y mis authorized_keys, known_hosts, y archivos clave pueden permanecer intactos.
Fuente
1
1
1
2014-09-04 08:33:25 +0000

Después de descubrir que no era el sistema, añadiendo un usuario de prueba (que el reenvío x funcionó “fuera de la caja”), pensé en empezar a copiar los archivos de inicio .bash* para virginar el usuario “roto”.

Ninguno de los archivos era diferente, así que lo siguiente que hice fue borrar el directorio .ssh de los usuarios. Cuando entré, se quejó de que “El servidor rechazó nuestra llave”, pero pude entrar usando la contraseña. Una vez conectado, podía hacer un reenvío perfecto.

Ahora intentaré configurar la clave de nuevo y veré si puedo hacer que funcione también. Entonces volverá a la normalidad.
Fuente
1
1
1
2019-09-17 06:35:46 +0000

Con privilegios de root abre /etc/ssh/sshd_config y descomenta las siguientes líneas si están comentadas:

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

Luego cierra la sesión y vuelve a iniciar sesión con la bandera de -X en ssh. No tienes que establecer o desestablecer la variable de entorno DISPLAY.
Fuente
0
0
0
2019-01-11 14:16:32 +0000

Me encontré con este mismo problema en dos servidores que técnicamente eran nodos hermanos. Me duele la cola, ya que no pude averiguar qué era diferente. Resulta que el directorio /home estaba lleno, por lo que los archivos .Xauthority no se podían poblar correctamente. Una vez que localicé los archivos que ocupaban demasiado espacio y los purgué, los nuevos archivos .Xauthority se crearon correctamente.
Fuente