xauth no crea el archivo .Xauthority

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

Además, cuando corro xauthme sale 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 conecto el monitor, luego inicio sesión localmente, el archivo se crea pero cuando trato de agregar 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, hacer una netstat --listenmuestra del puerto escuchando:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, más información. Salí de la sesión X en el servidor y ahora el archivo .Xauthority ha desaparecido. Parece que el archivo SOLO está allí cuando se inicia sesión localmente. ¿Alguien puede decirme por qué o cómo puedo solucionar esto?

NUEVO DESARROLLO:

Creé un usuario virgen en el sistema llamado "prueba". Luego inicié sesión, y sin NINGÚN otro comando, ejecuté xeyes. Que funcionó! Entonces es SOLO el usuario "marty" que no puede avanzar. ¿Cómo copio la configuración de prueba a marty?

Solo para informar, tuve un problema similar. Pero en mi caso solo sigo esos pasos :

Siga estos pasos para crear un $HOME/.Xauthorityarchivo.

Inicie sesión como usuario y confirme que está en el directorio de inicio 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 .Xauthorityarchivo desde entonces.

Gracias y créditos a srinivasan .

Sólo para complementar la excelente tonelada 's respuesta .

Una vez tuve el mismo problema porque mi directorio de inicio se había llenado al 100%. Tras la conexión, sshcreó un vacío ~/.Xauthorityy no pudo escribir ninguna entrada única en él (por lo que xauth listsiempre había producido una salida vacía).

Por lo tanto, sugiero que siempre se verifique el espacio libre (por ejemplo df -h:) y verifique eso xauth generatey xauth add, de hecho, haya tenido algún efecto ( xauth list).

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.

Mover el .sshdirectorio fuera del camino hizo que el reenvío 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 idea de dónde vino. Retirarlo ha solucionado el problema, y mis authorized_keys, known_hostsy archivos de claves pueden todos se mantengan intactas.

Bajo los privilegios de root, abra /etc/ssh/sshd_configy descomente las siguientes líneas si están comentadas:

X11 Reenvío sí

X11DisplayOffset 10

X11UtilizarLocalhost sí

Luego, cierre sesión y vuelva a iniciar sesión con la -Xmarca ssh. No tiene que establecer o desarmar DISPLAYla variable de entorno.

Encontré este mismo problema en dos servidores que técnicamente eran nodos hermanos. Dolor en mi cola, ya que no podía entender qué era diferente. Resulta que el directorio / home estaba lleno, por lo que los archivos .Xauthority no podían llenarse correctamente. Una vez que localicé los archivos que ocupaban demasiado espacio y los purgué, se crearon nuevos archivos .Xauthority correctamente.