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.
