Erros de encaminhamento de Xauth / X11 ssh com o arquivo .Xauthority não gravável

Question

Ao fazer login com ssh -Y remotehost , recebo a seguinte mensagem de erro:

/usr/bin/xauth: /home/hlovdal/.Xauthority not writable, changes will be ignored

E xclock e semelhantes não iniciam. Não há nada de errado com as permissões do arquivo .Xauthority, apesar da mensagem de erro.

(hlovdal) remotehost:~>xclock
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0
(hlovdal) remotehost:~>ls -l /home/hlovdal/.Xauthority
-rw-------. 1 hlovdal hlovdal 70 Jul 25 23:30 /home/hlovdal/.Xauthority
(hlovdal) remotehost:~>

Qual pode ser a causa aqui?

(Isso está entre os meus dois laptops, onde eu já havia andado e voltado centenas de vezes antes.)

Atualização:

Durante a depuração adicional, o xauth reclamou novamente que não era possível gravar em .Xauthority Isso não faz sentido, já que o arquivo é gravável pelo meu usuário, e fora de curiosamente eu corri para ver exatamente o que tentava fazer.

(hlovdal) remotehost:~>xauth list
xauth:  /home/hlovdal/.Xauthority not writable, changes will be ignored
(hlovdal) remotehost:~>strace -oout -f -s9000 xauth list
xauth:  error in locking authority file /home/hlovdal/.Xauthority
(hlovdal) remotehost:~>tail out
16634 brk(0xf03000)                     = 0xf03000
16634 brk(0)                            = 0xf03000
16634 rt_sigaction(SIGINT, {0x4050d0, [INT], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 rt_sigaction(SIGTERM, {0x4050d0, [TERM], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 rt_sigaction(SIGHUP, {0x4050d0, [HUP], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 rt_sigaction(SIGPIPE, {0x4050d0, [PIPE], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 stat("/home/hlovdal/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
16634 open("/home/hlovdal/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
16634 write(2, "xauth:  error in locking authority file /home/hlovdal/.Xauthority\n", 66) = 66
16634 exit_group(1)                     = ?
(hlovdal) remotehost:~>ls -l .Xauthority*
-rw-------. 1 hlovdal hlovdal 70 Jul 25 23:30 .Xauthority
-rw-------. 2 hlovdal hlovdal  0 Jul 26 01:26 .Xauthority-c
-rw-------. 2 hlovdal hlovdal  0 Jul 26 01:26 .Xauthority-l
(hlovdal) remotehost:~>

Isso explica melhor por que o xauth falha, pois falha ao criar .Xauthority-c. Mas remover esses dois arquivos provavelmente obsoletos não ajuda, eles são recriados no próximo login ssh. O syslog em remotehost contém o seguinte relacionado ao login do ssh.

sshd[17551]: Accepted publickey for hlovdal from x.x.x.x port 36545 ssh2
sshd[17552]: fatal: mm_request_receive: read: Connection reset by peer
sshd[17551]: pam_unix(sshd:session): session opened for user hlovdal by (uid=0)

Esta mensagem de erro mm_request_receive nunca ocorreu antes, então acho que existe a pista para mais depuração.

    

Answer 1

Este parece ser um problema já conhecido relatado no bugzilla do Redhat , então eu irei fechar "esta pergunta e continue relatando para esse relatório de bug.

    

Answer 2

Eu tive o mesmo problema depois de sincronizar minha pasta pessoal no Ubuntu 12.04. Eu resolvi usando os seguintes comandos:

rm ~/.Xaut* 

Em seguida, efetuei o login e fiz o login novamente. Após o aviso:

/usr/bin/xauth:  file /home/iranice/.Xauthority does not exist

Depois disso, o Linux criou o arquivo .Xauthority automaticamente. Eu fiz o logout e fiz o login novamente e tudo deu certo.

    

Answer 3

Para mim, tive esse erro:

/usr/bin/xauth: error in locking authority file /home/toto/.Xauthority

porque minha partição / home estava cheia.

Liberar algum espaço nessa partição resolveu esse problema.

O comando strace: strace -oout -f -s9000 xauth list foi útil na identificação do problema.

    

Answer 4

O problema para mim eram as permissões do SELinux. Eles devem ser configurados da seguinte forma:

chcon -Rv unconfined_u:object_r:xauth_home_t: s0 /PATH/.Xauthority