¿Por qué recibo este mensaje de xauth: "tiempo de espera en el archivo de autorización de bloqueo / home / <user> /.Xauthority"?

32

Al intentar SSH en un host, recibí el siguiente mensaje de xauth:

/ usr / bin / xauth: tiempo de espera en el archivo de autorización de bloqueo /home/sam/.Xauthority

NOTA: Estaba tratando de mostrar de forma remota una GUI X11 a través de una conexión SSH, por lo que necesitaba xauthpoder crear un $HOME/.Xauthorityarchivo con éxito, pero como ese mensaje indicaba, claramente no era así.

Intenta ejecutar cualquier aplicación basada en X11, como la que xeyesrecibió este mensaje:

$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0

¿Cómo puedo resolver este problema?

x11 remote-management xauth slm
fuente
1
Encontré esta página útil ya que mi problema se debía a que selinux estaba en modo de imposición, lo que impedía que el archivo se creara en primer lugar: twiki.cern.ch/twiki/bin/view/CLIC/LCDTroubleShooting
Gav Reichel

Respuestas:

39

Ejecutar un straceen el sistema remoto donde xauthestá fallando le mostrará lo que está ocurriendo xauth.

Por ejemplo

$ strace xauth list
stat("/home/sam/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0

Entonces xauthestá intentando abrir un archivo y ya existe. El archivo culpable es /home/sam/.Xauthority-c. Podemos confirmar la presencia de este archivo en el sistema remoto:

$ ls -l .Xauthority*
-rw------- 1 sam sam 55 Jul 12 22:04 .Xauthority
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-c
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-l

La solución

Como resulta. Esos archivos son archivos de bloqueo, por .Xauthoritylo que simplemente eliminarlos resuelve el problema.

$ rm -fr .Xauthority-*

Con los archivos eliminados, salga de la conexión SSH y luego vuelva a conectarse. Esto permitirá xauthvolver a ejecutar con éxito.

$ ssh -t skinner ssh sam@blackbird
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Sun Jul 12 22:37:54 2015 from skinner.bubba.net
$

Ahora podemos ejecutar xauth listaplicaciones X11 sin problemas.

$ xauth list
blackbird/unix:10  MIT-MAGIC-COOKIE-1  cf01f793d2a5ece0ea58196ab5a7977a

La GUI

$ xeyes

                                              ss # 1

Método alternativo para resolver el problema.

Me encontré con esta publicación titulada: xauth: error al bloquear el archivo de autoridad .Xauthority [linux, ssh, X11] que menciona el uso de xauth -bpara romper cualquier archivo de bloqueo que pueda estar dando vueltas. xauthLa página del manual parece respaldar esto:

 -b      This option indicates that xauth should attempt to break any
         authority file locks before proceeding.  Use this option only to
         clean up stale locks.

Referencias

slm
fuente
1
¿Sabes qué causó que esos archivos de bloqueo se dejen atrás?
Gilles 'SO- deja de ser malvado'
@Gilles: no, tuve el mismo pensamiento. Los eliminé y luego pensé que debería haber tratado de profundizar en lo que los controlaba usando lsof. Los había visto antes, pero no recuerdo dónde. Pensé que usted y yo los discutimos en un punto anterior, pero no pude encontrar ninguna mención de ellos en el sitio.
slm
1
Es posible que deba solucionar los problemas de SELinux antes de eliminar los archivos de autoridad. Ver froebe.net/blog/2015/01/20/…
MrMas
En mi caso, el archivo y el directorio tenían un propietario incorrecto (después de copiar el directorio de inicio del usuario en otra computadora).
Ken Sharp
En mi caso, los permisos para la carpeta / home / user eran en root:rootlugar de user:user. Fijado por chown user:user /home/user.
0andriy
8

La raíz del problema podría ser que no tiene permiso de escritura en el directorio $ HOME.

Es por eso que recibí este mensaje:

/ usr / bin / xauth: tiempo de espera en el archivo de autorización de bloqueo /home/fooftp/.Xauthority

Así es como verifiqué el permiso:

fooftp@for-fun-work:~> ls -l .Xauthority 
-rw-r--r-- 1 fooftp fooftp 1 Sep 14  2015 .Xauthority
# Conlusion: I can write this file: ok

fooftp@for-fun-work:~> rm .Xauthority
rm: cannot remove '.Xauthority': Permission denied
# Conlusion: strange ... I can't delete it 

fooftp@for-fun-work:~> id
uid=1001(fooftp) gid=1000(fooftp) groups=1000(fooftp)
# Conlusion: Yes, I am user fooftp

fooftp@for-fun-work:~> ls -ld .
dr-xr-xr-x 14 fooftp fooftp 4096 Sep 14  2015 .
# Conlusion: Bug found :-)
# The permissions should be "rwx" for you.

Si este es el problema, debe asegurarse de tener permisos de escritura en $ HOME:

chmod u+rwX $HOME
guettli
fuente
3

Tengo otra respuesta a la pregunta que me atormentó antes de resolver el problema. El problema es un error en el sistema operativo Fedora y sus derivados, como descubrí más tarde. Si el problema no es el indicado por la respuesta aceptada, y / o no estás en Fedora, RedHat, Korora, etc., entonces esto no te ayudará.

El problema

Como dijo el usuario slm, ejecutar strace le dará una indicación del problema, pero en el caso de este error en particular, el resultado es diferente:

$ strace xauth list
  ...
  stat64("/home/USER/.Xauthority-c", 0xbff23280) = -1 ENOENT (No such file or directory)
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
  ...

Para ser claros, esto indica que el código de retorno EACCES, que es un permiso denegado. Esto es diferente del problema del usuario slm, donde tenía el código de retorno EEXIST, lo que significa que existe el archivo. Entonces, para el código de retorno EACCES, obviamente lo primero que verifica es: ¿están configurados mis permisos de inicio para poder escribir en mi directorio de inicio? Primero debe verificar que tiene el indicador de escritura en su directorio personal para su propio usuario. Si lo hace, puede ser víctima del error que se describe a continuación.

El bicho

A través de un par de búsquedas en Google, finalmente pude encontrar a alguien con un problema similar, y me llevó al informe de errores de Fedora. Para aquellos de ustedes que deseen leer sobre esto: https://bugzilla.redhat.com/show_bug.cgi?id=772992

La solución

La solución al problema:

#verify you're not crazy
$ xauth list
  /usr/bin/xauth:  timeout in locking authority file /home/USER/.Xauthority
#use restorecon to reset it all
$ /sbin/restorecon -v -v /home/USER/.Xauthority 
$ /sbin/restorecon -v -v -R /home/USER/
#log out of the remote system
$ exit

Cuando vuelva a SSH, debería estar bien en este punto y debería poder transferir con éxito su sesión X nuevamente.

EDITAR (y otras soluciones alternativas):

Para ser lo más completo posible, otros usuarios declararon en el informe de error que la solución anterior no funcionó para ellos, resultó que funcionó para mí. Otro intento de solucionar el problema fue (no verifiqué esta solución personalmente):

# setsebool -P use_nfs_home_dirs 1

Otra persona menciona algo sobre GDM, del cual no tengo conocimiento. Si eso le pertenece, le recomiendo leer su publicación en BugZilla y ver si su comentario significa algo para usted.

motor de búsqueda27
fuente
1
En toda su extensión, esto no está claro. ¿Cuál es el problema? ¿Cuál es la solución / solución? ¿Qué hace? ¿Cuándo deberíamos esperar que la solución # 1 no funcione?
Scott
No entiendo lo que preguntas. La pregunta tenía un problema bastante claro. La solución 1 tenía una solución bastante clara para una variación de ese problema. La solución 1 tenía una forma bastante clara de indicar cuál era el problema específicamente en su respuesta. Mi problema fue claramente diferente, como se indicó anteriormente, por lo que mi solución para resolver ese problema también fue claramente diferente. ¿Sobre qué necesita aclaraciones para que esto sea más obvio?
searchengine27
Traté de hacer algunas actualizaciones a la respuesta, pero honestamente no sé cómo dejarlo más claro que eso sin saber qué es lo que le preocupa específicamente.
searchengine27
1
Confirmado y la solución soluciona el problema para CentOS 6.9
kap
0

La configuración de SELinux es lo primero que debe verificar, con ...

*/usr/sbin/sestatus*

o

*/usr/sbin/sestatus -v*

Si la configuración de SELinux se establece en "Aplicación" , puede estar causando el problema "xauth" .

 /usr/sbin/setenforce 0

Puede configurarlo provisionalmente en modo "permisivo" de la siguiente manera (para poder excluir este problema como la causa raíz del problema) .

Luego, siga un tutorial de SELinux para establecer una configuración adecuada o deshabilítela si prefiere otro método de seguridad (por ejemplo, editando el archivo de configuración / etc / selinux / config en RHEL v.6)

fjcobas
fuente