☰

xauth no crea el archivo .Xauthority

tag-icon • tag-icon linux ssh xauth
xauth no crea el archivo .Xauthority

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

Además, cuando ejecuto xauthobtengo 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 y luego inicio sesión localmente, se crea el archivo, pero cuando intento 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, al hacer un netstat --listense muestra el puerto escuchando:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, más información. Cerré la sesión X en el servidor y ahora el archivo .Xauthority ha desaparecido. Parece que el archivo SÓLO está ahí cuando se inicia sesión localmente. ¿Alguien puede decirme por qué o cómo puedo solucionar este problema?

NUEVO DESARROLLO:

Creé un usuario virgen en el sistema llamado "prueba". Luego inicié sesión y, sin NINGÚN otro comando, ejecuté xeyes. ¡Lo cual funcionó! Así que SÓLO el usuario "marty" no puede reenviar. ¿Cómo copio la configuración de test a marty?

Respuesta1

Sólo para informar, tuve un problema similar. Pero en mi caso solo sigoesos pasos:

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

Inicie sesión como usuario y confirme que se encuentra 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 .Xauthorityel archivo desde entonces.

Gracias y créditos asrinivasan.

Respuesta2

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

X11Reenvío sí

X11DisplayOffset 10

X11UseLocalhost sí

Luego cierre sesión y vuelva a iniciar sesión con -Xla bandera en ssh. No es necesario configurar o desarmar DISPLAYla variable de entorno.

Respuesta3

Sólo para complementar el excelentetonelada'srespuesta.

Una vez tuve exactamente el mismo problema porque mi directorio personal estaba 100% lleno. Al conectarse, sshcreó un vacío ~/.Xauthorityy no pudo escribir ninguna entrada en él (por lo que xauth listsiempre produjo una salida vacía).

Por lo tanto, sugiero que siempre se verifique el espacio libre (por ejemplo df -h:) y se verifique que xauth generateefectivamente xauth addhaya tenido algún efecto ( xauth list).

Respuesta4

Quitar el .sshdirectorio 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. Eliminarlo solucionó el problema y mis archivos authorized_keys, known_hostsy clave pueden permanecer intactos.

información relacionada