Tenho outra resposta para a pergunta que me atormentou antes de descobrir o problema. O problema é um bug no sistema operacional Fedora e seus derivados, como descobri mais tarde. Se o problema não for o indicado pela resposta aceita e / ou você não estiver no Fedora, RedHat, Korora, etc., isso não ajudará.
O problema
Como o usuário slm disse, o strace em execução fornecerá uma indicação do problema, mas neste caso de bug específico, a saída é 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 ficar claro, isso está afirmando que o código de retorno EACCES, que é permissão negada. Isso é diferente do problema do usuário slm, onde ele tinha o código de retorno EEXIST, o que significa que o arquivo existe. Portanto, para o código de retorno EACCES, obviamente, a primeira coisa que você verifica é: minhas permissões pessoais estão configuradas para que eu possa gravar no meu diretório pessoal? Você deve verificar se possui o sinalizador de gravação em seu diretório pessoal para o seu próprio usuário primeiro. Se você o fizer, poderá ser vítima do bug descrito abaixo.
O inseto
Através de algumas pesquisas no google, finalmente consegui encontrar alguém com um problema semelhante, e isso me levou ao relatório de erros do Fedora. Para aqueles que desejam ler sobre isso: https://bugzilla.redhat.com/show_bug.cgi?id=772992
A solução alternativa
A solução alternativa para o 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
Quando você fizer o SSH de volta, tudo ficará bem nesse momento e você poderá transferir com êxito sua sessão X novamente.
EDIT (e outras soluções alternativas):
Para ser o mais completo possível, outros usuários declararam no relatório de erro que a correção acima não funcionou para eles - aconteceu para mim. Outra tentativa de solucionar o problema foi (não verifiquei essa solução pessoalmente):
# setsebool -P use_nfs_home_dirs 1
Outra pessoa menciona algo sobre o GDM, do qual tenho zero conhecimento. Se isso lhe pertence, recomendo ler o post dele no BugZilla e ver se o comentário dele significa alguma coisa para você.
