Por que recebo esta mensagem do xauth: “tempo limite no arquivo de autoridade de bloqueio /home/user/.Xauthority”?

Question

Durante a tentativa de SSH em um host, recebi a seguinte mensagem de xauth :

/usr/bin/xauth: timeout in locking authority file /home/sam/.Xauthority

OBSERVAÇÃO: Eu estava tentando exibir remotamente uma GUI X11 por meio de uma conexão SSH, então precisei de xauth para poder criar um arquivo $HOME/.Xauthority com êxito, mas como essa mensagem estava indicando, claramente não foi.

As tentativas de executar aplicativos baseados no X11, como xeyes , foram recebidas com esta mensagem:

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

Como posso resolver este problema?

    

Answer 1

A execução de um strace no sistema remoto em que xauth está falhando mostrará o que está ocorrendo em xauth .

Por exemplo

$ 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

Portanto, xauth está tentando abrir um arquivo e ele já existe. O arquivo culpado é /home/sam/.Xauthority-c . Podemos confirmar a presença deste arquivo no 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

A correção

Como se constata. Esses arquivos são arquivos de bloqueio para .Xauthority , então simplesmente removê-los resolve o problema.

$ rm -fr .Xauthority-*

Com os arquivos excluídos, saia da conexão SSH e, em seguida, reconecte-se. Isso permitirá que xauth seja executado novamente com ê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
$

Agora, podemos executar os aplicativos xauth list e X11 sem problemas.

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

A GUI

$ xeyes

Métodoalternativopararesolveroproblema

Medepareicomestepostintitulado: xauth: erro no arquivo de autoridade de bloqueio .Xauthority [linux, ssh, X11] que menciona o uso de xauth -b para quebrar qualquer arquivo de bloqueio que possa estar por perto. A página man do xauth parece confirmar isso:

 -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.

Referências

• Lidando com xauth "erro ao bloquear o arquivo de autoridade" erros

Answer 2

A raiz do problema pode ser que você não tem permissão de gravação no diretório $ HOME.

É por isso que recebi esta mensagem:

/usr/bin/xauth: timeout in locking authority file /home/fooftp/.Xauthority

Veja como eu verifiquei a permissão:

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.

Se esse for o problema, você precisa ter certeza de que tem permissões de gravação para $ HOME:

chmod u+rwX $HOME

    

Answer 3

Eu tenho outra resposta para a pergunta que me atormentou antes de descobrir o problema. O problema é um bug no Fedora OS e seus derivados, como descobri mais tarde. Se o problema não for indicado pela resposta aceita e / ou você não estiver no Fedora, RedHat, Korora, etc, isso não ajudará você.

O problema

Como o usuário slm disse, executar strace lhe dará uma indicação do problema, mas no caso deste bug em particular, 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 ser claro, isso é afirmar 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 Arquivo existe. Portanto, para o código de retorno EACCES, obviamente, a primeira coisa que você verifica é: as permissões de minha casa estão configuradas para que eu possa gravar em meu diretório pessoal? Você deve verificar se você tem o sinalizador de gravação em seu diretório inicial para o seu próprio usuário primeiro. Se você fizer isso, então você pode ser uma vítima do bug descrito abaixo.

O erro

Por meio de algumas pesquisas no google, finalmente consegui encontrar alguém com um problema semelhante, e isso me levou ao relatório de bug do Fedora. Para aqueles de vocês que gostam de ler sobre isso: link

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, ele deve estar bem e você poderá transferir com sucesso sua sessão X novamente.

EDIT (e outras alternativas):

Apenas para ser o mais completo possível, outros usuários afirmaram no relatório de erros que a correção acima não funcionou para eles - aconteceu que funcionou para mim. Outra tentativa de contornar o problema foi (eu não verifiquei essa solução pessoalmente):

# setsebool -P use_nfs_home_dirs 1

Outra pessoa menciona algo sobre o GDM, que eu não tenho conhecimento. Se isso se refere a você, eu recomendo ler o post dele no BugZilla e ver se o comentário dele significa alguma coisa para você.

    

Answer 4

A configuração do SELinux é a primeira coisa a verificar, com ...

*/usr/sbin/sestatus*

ou

*/usr/sbin/sestatus -v*

Se a configuração do SELinux estiver definida como "Reforçando" , isso pode estar causando o problema "xauth" .

 /usr/sbin/setenforce 0

Você pode configurá-lo provisoriamente para o modo "permisive" da seguinte forma, (para poder excluir esse problema como causa raiz do problema) .

Em seguida, siga um tutorial do SELinux para colocar em prática uma configuração adequada, ou desabilite-o se preferir outro método de segurança, (f.ex.by editando o arquivo de configuração / etc / selinux / config em RHEL v.6)