Proxy PuTTY X11: tentativa de protocolo de autorização errado


13

Estou tentando conectar-me a um servidor Ubuntu para trabalhar no Qt-creator. Antes de tudo dar errado, segui este tutorial. Eu baixei massa e Xming e tudo estava funcionando muito bem.

de repente, enquanto trabalhava no Qt-creator, não pude salvar nenhuma alteração. Então, fechei o Qt-creator e reiniciei a sessão de massa. ele me perguntou sobre nome de usuário e senha (como de costume), depois do login no servidor e quando tentei executar o Qt-creator (como de costume), a seguinte mensagem aparece:

PuTTY X11 proxy: wrong authorisation protocol attempted
Can't open display: localhost:10.0

tentei resolver o problema usando duas abordagens encontradas na internet:

o primeiro é obtendo o dpyname protoname hexkeyuso:

xauth list 

que deve retornar a chave que pode ser adicionada usando:

xauth add

No entanto, não funcionou, pois o xauth listcomando não retornou nada.

a segunda solução era ir para:

./etc/ssh/sshd_config

abra o arquivo: sshd_config e edite a ForwardX11Trustedlinha a ser lida yese, se essa linha não existir, adicione-a.

ForwardX11Trusted yes

reinicie o servidor ssh e ele deve funcionar.

No entanto, também não funcionou. Não foi possível abrir o arquivo sshd_configusando xdg-openou gedite a mesma mensagem aparece novamente.

Então, por que isso está acontecendo e qual é a solução para isso?


A boa notícia é: agora posso abrir o arquivo: sshd_configusando o sudo nanocomando e adicionar a linha: ForwardX11Trusted yes.. a má notícia é: após a "etapa de adição" o problema ainda existe !!!
— McLan

Qual é o comando completo quando você usa xauth add?
— Nate de Kalamazoo

ForwardX11Trustedé uma opção para o cliente OpenSSH, não para o servidor. Adicioná-lo pode impedir a sshdinicialização, dependendo da versão.
— Gert van den Berg

Respostas:


7

Enquanto estava logado como su, depois de alguns erros do tipo "proxy PuTTY X11: tentativa de protocolo de autorização errado" ", percebi que era um problema de autenticação. Lembrei-me de copiar o arquivo .Xauthority do meu próprio perfil / diretório pessoal para / root. Problema resolvido!


Isso parece ser a resposta para um problema diferente (embora com os mesmos sintomas).
— DavidPostill

Isso funcionou para Raspbian Jessie em RaspberryPi
— Dexter

Isso também funcionou para mim no RPI. De PuTTy no Win10 simples leafpadfuncionou bem, mas sudo leafpadgerou erro na descrição acima. A cópia .Xauthorityfuncionou perfeitamente. Muito obrigado!
— Petr Újezdský

ok para o problema de autorização ... mas ainda me dá "pode exibir não aberto:" ... alguma idéia?
— ZEE

2

Resolvido.

Eu o resolvi usando uma mistura dos dois mencionados acima.

1. Adicionei a seguinte linha ao '/ etc / ssh / sshd_config'

ForwardX11Trusted yes

2. Instalei o xauth usando

sudo apt-get install xauth

xauth listestava vazio para mim antes de reiniciar. Foi, no entanto, preenchido após o reinício. Eu fiz xauth listdepois que testei com massa de vidraceiro.

Então eu reiniciei o ssh e funcionou. Yay!

Nota: O que realmente fiz foi reiniciar o meu Raspberry Pi


3
ForwardX11Trusted não é uma opção válida para sshd_config. É um parâmetro de cliente, e não um parâmetro daemon servidor
— HeatfanJohn

Eu tinha feito isso há algum tempo. Não sei agora.
— Dheeraj Bhaskar

2

Eu tive um problema semelhante em um servidor no trabalho porque a pasta inicial estava sem espaço em disco. Após o login, ele não conseguiu gravar o arquivo Xauthority e ... não pôde encaminhar.

A liberação de espaço resolveu o problema.

Eu imagino que você teria um problema semelhante se as permissões da pasta pessoal ou .Xauthority fossem definidas incorretamente para que você não tivesse acesso de gravação.


1

No meu caso, notei que podia abrir o Display com root, mas estava fazendo uma su-grid, e essa grade de usuário era a que apresentava o problema,

a solução foi fechar esta sessão e abrir uma nova sessão diretamente com a grade, e funcionou, algo sobre fazer a su-grade estava falhando ...


0

Eu tive um problema semelhante em um servidor. O motivo foi que o usuário obteve o número errado de exibição (DISPLAY = localhost: 10.0). Quando o usuário se conecta ao servidor via SSH (como o usuário chamado test1), ele obtém DISPLAY = localhost: 11.0. Quando ele se conecta como outro usuário e se torna usuário (teste1), ele obtém o número errado de exibição (DISPLAY = localhost: 10.0). Quando eu defino o número certo de DISPLAY (DISPLAY = localhost: 11.0), ele funciona.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.