2014-09-03 10:44:44 +0000 2014-09-03 10:44:44 +0000
30
30

xauth não cria um ficheiro .Xauthority

Quando eu me meto num sistema Linux Mint 17 sem cabeça, ele não cria um ficheiro .Xauthority.

Além disso, quando corro xauth recebo a resposta: 

marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>exit
marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>

Não cria o ficheiro.

EDIT:

Quando ligo o monitor, depois inicio sessão localmente, o ficheiro é criado mas quando tento adicionar uma entrada (porque o meu SSH não o faz por mim): 

marty@N40L ~ $ xauth list
N40L/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
marty@N40L ~ $ ls -d .X*
-rw------- 1 marty marty 115 Sep 3 12:03 .Xauthority
marty@N40L ~ $ xauth generate $DISPLAY .
PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1: unable to open display "localhost:10.0".

Incidentalmente, fazer um netstat --listen mostra a escuta da porta: 

tcp 0 0 localhost:6010 *:* LISTEN

AGH, mais informação. Saí da sessão X no servidor, e agora o ficheiro .Xauthority desapareceu. Parece que o ficheiro só está lá quando se faz o log in localmente. Alguém me pode dizer porquê, ou como posso resolver isto?

NOVO DESENVOLVIMENTO:

Eu criei um utilizador virgem no sistema chamado “test”. Depois entrei no sistema, e sem qualquer outro comando, executei xeyes. O que funcionou! Então é APENAS o utilizador “marty” que não pode xforward. Como faço para copiar as configurações do teste para marty?
Fonte

Respostas (6)

35
35
35
2015-07-16 04:15:44 +0000

Só para informar, tive um problema semelhante. Mas no meu caso apenas segui esses passos :

Siga estes passos para criar um ficheiro $HOME/.Xauthority.

Entre como utilizador e confirme que está no directório home do utilizador. 

# Rename the existing .Xauthority file by running the following command
mv .Xauthority old.Xauthority 

# xauth with complain unless ~/.Xauthority exists
touch ~/.Xauthority

# only this one key is needed for X11 over SSH 
xauth generate :0 . trusted 

# generate our own key, xauth requires 128 bit hex encoding
xauth add ${HOST}:0 . $(xxd -l 16 -p /dev/urandom)

# To view a listing of the .Xauthority file, enter the following 
xauth list

Depois disso não há mais problemas com o ficheiro .Xauthority desde então.

Obrigado e créditos a srinivasan .
Fonte
4
4
4
2018-02-20 15:30:16 +0000

Só para complementar as excelentes ton ’s resposta .

tive em tempos exactamente o mesmo problema porque o meu directório de casa tinha ficado 100% cheio. Após a ligação, o ssh criou um ~/.Xauthority vazio e não conseguiu escrever nenhuma entrada nele (pelo que o xauth list tinha sempre produzido uma saída vazia).

Por isso sugiro que se verifique sempre o espaço livre (por exemplo: df -h) e que se verifique que o xauth generate e o xauth add tiveram de facto algum efeito (xauth list).
Fonte
1
1
1
2015-05-20 14:06:07 +0000

Ao mover o directório .ssh para fora do caminho fiz X forwarding trabalhar para mim.

Através do processo de eliminação, encontrei um ficheiro em ~/.ssh que se chamava “rc”, e continha: 

echo "Wecome to $(hostname), $(whoami)"

Nunca criei isto, e não faço ideia de onde veio. Removendo-o corrigi o problema, e os meus authorized_keys, known_hosts, e ficheiros chave podem ficar todos intactos.
Fonte
1
1
1
2014-09-04 08:33:25 +0000

Depois de descobrir que não era o sistema, ao adicionar um utilizador de teste (que x encaminhamento funcionava “out the box”), pensei em começar a copiar os ficheiros de arranque .bash* para virginizar o utilizador “quebrado”.

Nenhum dos ficheiros era diferente, por isso a seguir apaguei o directório .ssh dos utilizadores. Quando o ssh entrou, gemeu sobre “Server refused our key”, mas eu pude entrar usando senha. Uma vez logado, eu podia x encaminhar perfeitamente.

Agora vou tentar configurar a chave novamente e ver se consigo pôr isso a funcionar também. Depois voltará ao normal.
Fonte
1
1
1
2019-09-17 06:35:46 +0000

Sob privilégios raiz abrir /etc/ssh/sshd_config e descomentar as seguintes linhas se forem comentadas:

X11Arrancar sim

X11DisplayOffset 10

X11UseLocalhost sim

Depois sair e entrar novamente com a bandeira -X em ssh. Não tem de definir ou desactivar a variável de ambiente DISPLAY.
Fonte
0
0
0
2019-01-11 14:16:32 +0000

Deparei-me com esta mesma questão em dois servidores que eram tecnicamente nós irmãos. Dor na minha cauda, pois não conseguia perceber o que era diferente. Acontece que o diretório /home estava cheio, então os arquivos .Xauthority não podiam ser preenchidos corretamente. Assim que localizei o(s) ficheiro(s) ocupando demasiado espaço e os purguei, novos ficheiros .Xauthority foram criados correctamente.
Fonte