☰

Como faço para depurar “Conexão X11 rejeitada devido a autenticação errada”

tag-icon • tag-icon ssh logging debug x11-forwarding
Como faço para depurar “Conexão X11 rejeitada devido a autenticação errada”

Tenho um problema com o encaminhamento do X por meio de SSH. Lutei por muito tempo, mas ninguém consegue ajudar.

Agora estou adotando uma tática diferente. Gostaria de saber como depuraria os erros?

Quais logs devo procurar, quais sinalizadores extras devo definir (-v etc) e o que devo procurar?

Edição adicional:

Se eu fizer login no Putty no servidor e tentar xeyes, recebo:

Proxy PuTTY X11: tentativa de protocolo de autorização incorretoErro: não é possível abrir a tela: localhost:10.0

Se eu xauth generate $DISPLAYconseguir:

Proxy PuTTY X11: tentativa de protocolo de autorização incorretoxauth: (argv):1: não foi possível abrir a exibição "localhost:10.0".

Responder1

Minha solução passo a passo:

1) faça login com a opção -X raiz de login do host remoto

$ssh-X[e-mail protegido]

2) verifique se o arquivo .Xauthority existe

[root@localhost ~]#ls -al
[root@localhost ~]# vim .Xauthority

3) copie o arquivo .Xauthority para o diretório do outro usuário

[root@localhost ~]# cp .Xauthority /home/oracle/
cp: substituir `/home/oracle/.Xauthority'? sim

4) defina permissões para este arquivo

[root@localhost ~]# chown oracle:oinstall .Xauthority
[root@localhost ~]# chmod 0600 .Xauthority

5) faça login como usuário oracle

[root@localhost ~]#su - oracle

6) configuração de exibição em localhost:10.0

[oracle@localhost ~]$ echo $DISPLAY
host local: 10.0
[oracle@localhost ~]$ ls -al

7) lista os cookies xauth existentes

[oracle@localhost ~]$ lista xauth
localhost.localdomain/unix:11 MIT-MAGIC-COOKIE-1 310f1b02c1080e73059391c193a1881b
localhost.localdomain/unix:10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb759

8) adicionando

[oracle@localhost ~]$ xauth add localhost.localdomain/unix:10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75

9) teste

[oracle@localhost ~]$ xclock

Espero que sirvam! @wcaraza

Responder2

Certifique-se de que o servidor SSH tenha a xauthferramenta instalada e que seu ~/.Xauthorityarquivo seja gravável. (Inexistente também está bem, desde que xauthseja possível criá-lo.)

Verifique se os dados do xauth estão sendo atualizados:

server$ xauth list

Tente adicionar manualmente dados xauth fictícios (novamente, no servidor SSH) e veja se xauthhá algum problema (por exemplo, não conseguir criar o arquivo de bloqueio ou modificar o próprio arquivo Xauthority):

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

Se necessário, execute novamente em strace.

Execute o serviço SSH no modo de depuração, configurando LogLevel DEBUG2na configuração do servidor ( /etc/ssh/sshd_config), ou iniciando o sshd diretamente no modo de depuração:

server$ sshd -rddp 12234

(Neste exemplo, 12234é a porta SSH temporária à qual você precisa se conectar. Qualquer porta livre serve.)

Responder3

Está funcionando, está funcionando. haha.

FINALMENTE.

Depois de descobrir que não era o sistema, adicionando um usuário de teste (que x forwarding funcionou "pronto para usar"), pensei em começar a copiar os arquivos de inicialização .bash* para virginizar o usuário "quebrado".

Nenhum dos arquivos era diferente, então excluí o diretório users .ssh. Quando entrei, ele reclamou que "O servidor recusou nossa chave", mas consegui fazer login usando a senha. Uma vez logado, eu poderia avançar perfeitamente.

Agora tentarei configurar a chave novamente e ver se consigo fazer isso funcionar também. Depois voltará ao normal.

Responder4

rm ~/.Xauth*e reconecte.

Isso funciona para mim. Para maisdetalhes

informação relacionada