xauth não criando arquivo .Xauthority

28

Quando ssh em um sistema Linux Mint 17 sem cabeça, ele não cria atualização / cria um arquivo .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 arquivo.

EDITAR:

Quando conecto o monitor e efetuo 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".

Aliás, fazer um netstat --listenmostra 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 SÓ está lá quando conectado localmente. Alguém pode me dizer por que, ou como posso corrigir isso?

NOVO DESENVOLVIMENTO:

Eu criei um usuário virgem no sistema chamado "teste". Então entrei e, sem outros comandos, executei xeyes. O que funcionou! Portanto, é SOMENTE o usuário "marty" que não pode avançar. Como copiar as configurações do teste para o martty?

linux ssh xauth

— wkdmarty
fonte

Você disse para criar o arquivo? ssh -Xativa o encaminhamento X11.

— grawity

Sim, estou usando o Putty no Windows, configurado para encaminhamento (funciona na conexão com outro servidor Mint). Mas o arquivo não é criado, então pensei em adicioná-lo manualmente, o xauth também não o cria manualmente.

— Wkdmarty 3/09/14

O Xwindows local cria o arquivo .Xauthority, mas a sessão Putty SSH não. Mesmo que ele mostre a escuta da conexão.

— Wkdmarty 3/09/14

34

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

Siga estas etapas para criar um $HOME/.Xauthorityarquivo.

Efetue login como usuário e confirme que você está no diretório inicial 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 .Xauthorityarquivo desde então.

Obrigado e créditos a srinivasan .

— tonelada
fonte

1

no meu caso, eu tinha uma variável de ambiente XAUTHORITY apontando para outro lugar (um erro descuidado), usando este [ prefetch.net/blog/index.php/2011/11/01/… thread que consegui descobrir isso e resolver o problema erro. Usando strace xauth, ele apontou o caminho incorreto especificado na variável. Gostaria também de acrescentar que eu estava ficando bloqueio erros aswel, entre outros

— Cybex

1

No meu caso, eu só precisei executar as etapas 1 a 3. As etapas 4 e 5 realmente não deram certo.

— precisa

Eu tenho que fazer xauth generate :0 . trusteddepois de cada comando como userabrir uma tela como root. Posso consertar?

— Timo

xhost +ajudou a abrir x-apps como root.

— Timo

7

Passo 3 dá-me o erro:xauth: (argv):1: unable to open display ":0".

— simpleuser

4

Só para complementar o excelente tonelada de resposta .

Uma vez tive exatamente o mesmo problema porque meu diretório pessoal ficou 100% cheio. Na conexão, sshcriou um vazio ~/.Xauthoritye não pôde gravar nenhuma entrada única (para que xauth listsempre produzisse uma saída vazia).

Então eu sugiro sempre se verifica o espaço livre (por exemplo: df -h) e verifica se xauth generatee xauth addde fato teve qualquer efeito ( xauth list).

— Graves
fonte

1

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

Nenhum dos arquivos era diferente; portanto, a seguir, excluí o diretório .ssh dos usuários. Quando eu fiz o SSH, ele gemia sobre "O servidor recusou nossa chave", mas eu consegui entrar usando a senha. Uma vez logado, eu poderia x encaminhar perfeitamente.

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

— wkdmarty
fonte

1

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

Através do processo de eliminação, encontrei um arquivo em ~ / .ssh chamado "rc" e continha:

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

Eu nunca criei isso e não tenho idéia de onde ele veio. Removê-lo corrigido o problema, e os meus authorized_keys, known_hostse arquivos de chave pode ficar todos intactos.

— billq
fonte

1

Em privilégios de root, abra /etc/ssh/sshd_confige remova o comentário das seguintes linhas, se elas forem comentadas:

X11Encaminhamento sim

X11DisplayOffset 10

X11UseLocalhost sim

Então saia e entre novamente com a -Xbandeira ssh. Você não precisa definir ou desabilitar DISPLAYa variável de ambiente.

— varsh
fonte

0

Me deparei com esse mesmo problema em dois servidores que eram tecnicamente nós irmãos. Dor no meu rabo, como eu não conseguia descobrir o que era diferente. Acontece que o diretório / home estava cheio; portanto, os arquivos .Xauthority não puderam ser preenchidos corretamente. Depois que localizei o (s) arquivo (s) ocupando muito espaço e limpei-os, novos arquivos .Xauthority foram criados corretamente.

— Linux_User
fonte