xauth não está criando o arquivo .Xauthority

Question

Quando eu ssh em um sistema Linux Mint 17 sem cabeçalho, ele não cria atualização / criação de um arquivo .Xauthority.

Além disso, quando executo 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 arquivo.

EDITAR:

Quando eu conecto o monitor e faço login localmente, o arquivo é criado, mas quando tento adicionar uma entrada (porque meu SSH não faz isso 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".

Por acaso, fazer um netstat --listen mostra a porta escutando:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, mais informações. Saí da sessão X no servidor e agora o arquivo .Xauthority desapareceu. Parece que o arquivo está lá apenas quando logado localmente. Alguém pode me dizer por que, ou como eu posso consertar isso?

NOVO DESENVOLVIMENTO:

Eu criei um usuário virgem no sistema chamado "teste". Então eu entrei e, sem qualquer outro comando, rodei xeyes. Que funcionou! Então é só o usuário "marty" que não pode xforward. Como faço para copiar as configurações do teste para o mártir?

    

Answer 1

Depois de descobrir que não era o sistema, adicionando um usuário de teste (que x encaminhamento funcionava "fora da caixa"), pensei em começar a copiar os arquivos de inicialização .bash * para virginise o "quebrado" "usuário.

Nenhum dos arquivos era diferente, então, em seguida, apaguei o diretório .ssh dos usuários. Quando eu ssh'd em, lamentou sobre "Servidor recusou nossa chave", mas eu poderia entrar usando a senha. Uma vez logado, eu poderia x avançar perfeitamente.

Agora vou tentar configurar a chave novamente e ver se consigo fazer isso funcionar também. Então voltará ao normal.

    

Answer 2

Só para informar, eu tive um problema semelhante. Mas no meu caso eu apenas sigo essas etapas :

Siga estas etapas para criar um arquivo $HOME/.Xauthority .

Faça login como usuário e confirme se você está no diretório pessoal do usuário.

# 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 arquivo .Xautority desde então.

Obrigado e créditos para srinivasan .

    

Answer 3

Apenas para complementar o excelente nosso ' responder .

Eu já tive exatamente o mesmo problema porque meu diretório inicial estava 100% cheio. Na conexão, ssh criou um ~/.Xauthority vazio e não pôde gravar nenhuma entrada nela (de modo que xauth list sempre produziu uma saída vazia).

Por isso, sugiro que sempre verifique o espaço livre (por exemplo, df -h ) e verifique se xauth generate e xauth add tiveram algum efeito ( xauth list ).

    

Answer 4

Mover o diretório .ssh para fora do caminho fez o encaminhamento do X funcionar para mim.

Por meio do processo de eliminação, encontrei um arquivo em ~ / .ssh que foi chamado de "rc" e continha:

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

Eu nunca criei isso e não tenho ideia de onde ele veio. A remoção corrigiu o problema e meus arquivos authorized_keys , known_hosts e key podem permanecer intactos.