Falha no SSH XForwarding - nome de exibição inválido do xauth

Estou tentando configurar o XForwarding pelo ssh, mas ele falha. O mesmo resultado acontece se eu usar o argumento -X ou -Y para ssh. O erro que eu recebo.

a@ASUS-N53SM:~$ ssh -X -p 6623 pinker@192.168.0.200
pinker@192.168.0.200's password: 
Last login: Sun Feb  2 18:42:08 2014 from 192.168.0.201
/usr/bin/xauth: (stdin):1:  bad display name "pinker-server:10.0" in "remove" command
/usr/bin/xauth: (stdin):2:  bad display name "pinker-server:10.0" in "add" command
xdpyinfo:  unable to open display "pinker-server:10.0".

No arquivo do cliente ~ / .ssh / config

ForwardX11 yes

No arquivo do cliente / etc / ssh / ssh_config (comentários removidos).

Host *
ForwardX11 yes
ForwardX11Trusted yes
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes 
GSSAPIDelegateCredentials no

No arquivo do servidor / etc / ssh / sshd_config (comentários removidos).

Port 6623
Port 6624
Port 6625
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
X11UseLocalhost no
AllowTcpForwarding yes

Encontrei essa pergunta semelhante , mas nenhuma das respostas funciona.

ATUALIZAR:

No servidor, adicionei ao arquivo / etc / hosts.

127.0.0.1       pinker-server

No servidor, instalei o pacote xbase-clients. Nas echo $DISPLAYsaídas de conexão ssh :0.0.

Agora estou recebendo um novo erro.

X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
xdpyinfo:  unable to open display "pinker-server:10.0".

Na máquina remota, edite o arquivo / etc / ssh / sshd_config. Mude X11UseLocalhostpara sim.

Fonte http://www.pclinuxos.com/forum/index.php?topic=109487.0

Esse erro ocorre quando a máquina remota não sabe seu próprio nome de host ou possui um nome de host incorreto associado ao 127.0.1.1 (NOTA: Não o 127.0.0.1 que sempre deve ser resolvido para o host local).

Para corrigi-lo, verifique se a entrada em / etc / hosts para 127.0.1.1 corresponde ao FQDN da máquina e ao nome abreviado do host.

Sempre que encontro um problema de SSH, quase imediatamente executo o comando com mais mensagens detalhadas ativadas. Eu gosto de usar essa técnica para coletar o arquivo de log no servidor do qual estou executando ssh. Se você precisar obter mais detalhes, basta adicionar mais -vopções (o máximo é 3).

$ ssh -v user@remoteserver |& tee /path/to/sshv1.log
-or-
$ ssh -vv user@remoteserver |& tee /path/to/sshv2.log

Conexão X11 rejeitada devido a autenticação incorreta.

Essa mensagem quase sempre indica um problema de permissão no seu .Xauthorityarquivo. Você pode afastar temporariamente o existente ou tentar corrigir sua propriedade e permissões.

$ chown user:group ~/.Xauthority
$ chmod 0600 ~/.Xauthority

Se o problema não for resolvido por nenhuma dessas operações, você poderá tentar diagnosticar os xauthcookies mágicos.

como usuário local executando ssh

$ xauth list
localhost/unix:13 MIT-MAGIC-COOKIE-1 c77169a6fa8139ea36f538e1c72e1b98

tão rosado no servidor

$ xauth
Using authority file /home/pinker/.Xauthority

Em seguida, adicione a chave manualmente:

xauth> add localhost/unix:13 MIT-MAGIC-COOKIE-1 c77169a6fa8139ea36f538e1c72e1b98

Referências

• Conexão Linux X11 rejeitada devido a erro e solução de autenticação incorreta

Eu obtive a maioria dessas informações em http://openvz.org/X_inside_VE#X_forwarding

Verifique X no SSH

Após o login via SSH, verifique se o encaminhamento do X está funcionando procurando a variável de ambiente DISPLAY:

echo $DISPLAY

A resposta deve ser algo como localhost:8.0

Verifique se o sshd permite o encaminhamento do X

Edite /etc/ssh/sshd_confige verifique se ele possuiX11Forwarding yes

Caso contrário, edite ou adicione a linha com o X11Fordwarding e reinicie o sshd:

service sshd restart( /etc/init.d/sshd restartestá usando o CentOS 5)

Então saia e entre novamente

Verifique se o xauth está configurado

Verifique se o pacote xauth foi instalado. No Debian, isso faz parte do xbase-clientspacote.

Ainda não está funcionando

Na pergunta que estou respondendo, a mensagem de erro é esta: /usr/bin/xauth: (stdin):1: bad display name "pinker-server:10.0" in "remove" command

Uma solução possível, sugerida abaixo, é garantir que a linha relevante sshd_configfique assim:

X11UseLocalhost yes

Deparamos com esse problema após a atualização do Gentoo. Esta página é o primeiro resultado do google para 'adicionar nome de exibição unix no comando add'. Nenhuma das soluções descritas aqui ajudou. A solução alternativa está escrita na descrição do bug do debian (segundo link na página de pesquisa do Google mencionada anteriormente):

sethostname any-name-here

após a execução do 'sethostname vvk', posso efetuar logon com o X-forwarding como antes. Essa resposta é digitada no navegador que está sendo executado no primeiro shell apropriado conectado ao servidor remoto.

Para mim funciona como um charme sshd_config

    Protocol 2
AuthorizedKeysFile  .ssh/authorized_keys
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
X11Forwarding yes
X11UseLocalhost yes
UsePrivilegeSeparation yes      # Default for new installations.
Banner /etc/issue.net
Subsystem   sftp    /usr/libexec/openssh/sftp-server
Ciphers aes256-ctr,aes192-ctr,aes128-ctr,arcfour256
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1,umac-64@openssh.com,hmac-ripemd160

ssh_config

Host *
   ForwardX11trusted yes
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes

E use

ssh -X remotehost

é claro que o servidor Xorg deve estar instalado completo (usando groupinstall, boa ideia)