xauth no crea el archivo .Xauthority

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 .

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).

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.

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.

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.

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.