SSH X11 não está funcionando

Eu tenho um computador em casa e no trabalho, o computador em casa tem um endereço IP estático.

Se eu ssh do meu computador do trabalho para o meu computador doméstico, a conexão ssh funciona, mas os aplicativos X11 não são exibidos.

No meu /etc/ssh/sshd_configem casa:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

No trabalho, tentei os seguintes comandos:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Meu /etc/ssh/ssh_configno trabalho:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Meu ~/.ssh/configno trabalho:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Meu ~/.Xauthorityno trabalho:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Meu ~/.Xauthorityem casa:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Mas isso não funciona

Depois de fazer uma conexão ssh para casa:

$ echo $DISPLAY
localhost:10.0

$ kate
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.
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.
kate: cannot connect to X server localhost:10.0

Uso iptablesem casa, mas permiti a porta 22. De acordo com o que li, é tudo o que preciso.

UPD. Com-vvv

...
debug2: início do retorno de chamada
debug2: x11_get_proto: / usr / bin / xauth list: 0 2> / dev / null
debug1: Solicitando o encaminhamento do X11 com falsificação de autenticação.
debug2: canal 1: solicitação x11-req confirm 1
debug2: client_session2_setup: id 1
debug2: configuração do fd 3 TCP_NODELAY
debug2: channel 1: request pty-req confirm 1
...

Ao tentar iniciar kate:

debug1: client_input_channel_open: ctype x11 rchan 2 vitória 65536 máximo 16384
debug1: client_request_x11: request from 127.0.0.1 55486
debug2: configuração do fd 8 O_NONBLOCK
debug3: o fd 8 é O_NONBLOCK
debug1: canal 2: novo [x11]
debug1: confirme x11
A conexão debug2: X11 usa um protocolo de autenticação diferente.
Conexão X11 rejeitada devido a autenticação incorreta.
debug2: X11 rejeitou 2 i0 / o0
debug2: canal 2: falha na leitura
debug2: canal 2: close_read
debug2: canal 2: entrada aberta -> drenagem
debug2: canal 2: ibuf vazio
debug2: canal 2: enviar eof
debug2: canal 2: dreno de entrada -> fechado
debug2: canal 2: falha na gravação
debug2: canal 2: close_write
debug2: canal 2: saída aberta -> fechada
debug2: X11 fechado 2 i3 / o3
debug2: canal 2: envia perto
debug2: canal 2: rcvd fechar
debug2: canal 2: está morto
debug2: canal 2: coleta de lixo
debug1: canal 2: grátis: x11, nchannels 3
debug3: channel 2: status: As seguintes conexões estão abertas:
  # 1 sessão de cliente (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# O mesmo que acima repita cerca de 7 vezes

kate: não é possível conectar ao servidor X localhost: 10.0

UPD2 Forneça sua distribuição Linux e número da versão.
Você está usando um ambiente GNOME ou KDE padrão para o X ou algo mais que você personalizou?

azat: ~ $ kded4 -version
Qt: 4.7.4
Plataforma de Desenvolvimento KDE: 4.6.5 (4.6.5)
Daemon do KDE: $ Id $

Você está chamando o ssh diretamente em uma linha de comando a partir de uma janela do terminal?
Qual terminal você está usando? xterm, gnome-terminal ou?
Como você iniciou o terminal em execução no ambiente X? De um menu? Tecla de atalho? ou?

Do emulador de terminal `yakuake`
Pressione manualmente `Ctrl + N` e escreva comandos

Você pode executar xeyes na mesma janela do terminal em que o ssh -X falha?

`xeyes` - não está instalado
Mas o `kate` ou outro aplicativo kde está sendo executado

Você está chamando o comando ssh como o mesmo usuário em que você fez logon na sessão X?
From the same user

UPD3

Também faço o download de sshfontes e, usando o debug2()write, porque é que a versão é diferente?
Veja alguns cookies e um deles está vazio, outro éMIT-MAGIC-COOKIE-1

O motivo pelo qual o encaminhamento do ssh X não estava funcionando foi porque eu tenho um /etc/ssh/sshrcarquivo de configuração.

O final da sshd(8)página do manual indica:

Se ~/.ssh/rcexistir, execute-o; caso contrário, se /etc/ssh/sshrcexistir, execute-o; caso contrário, executa o xauth

Então, adiciono os seguintes comandos /etc/ssh/sshrc(também na página do manual sshd) no lado do servidor:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

E funciona!

Sempre que você estiver tendo problemas com o ssh, a primeira coisa que você deve fazer é executar o cliente com a -vopção de fornecer essa saída para que outras pessoas inspecionem:

ssh -v user@somewhere

Eu acho que o problema está no seu sistema local. Como você está chamando o comando ssh? Você está executando manualmente em um shell? Ou está sendo executado como parte de um script? Em ambos os casos, convém garantir que o sistema local tenha o DISPLAYambiente definido corretamente. Também precisa ser definido corretamente no lado remoto, mas esse valor será diferente no lado remoto e no lado local.

Pelo que você escreveu, parece que ele está sendo configurado corretamente no host remoto (e, por extensão, o encaminhamento do X11 está sendo configurado corretamente pelo ssh). No sistema remoto você tem:

$ echo $DISPLAY
localhost:10.0

O que isso está mostrando no lado local? Isso deve ser fácil de verificar se você está em um shell, repetindo o valor e iniciando um aplicativo X a partir desse shell ... você sempre pode usar o venerável xeyespara esse tipo de teste, é claro! :)

Por outro lado, se você estiver chamando o comando ssh de um script ou anexado a uma tecla de atalho, ele poderá não herdar o ambiente que você espera, portanto, DISPLAYa variável de ambiente no lado local poderá não estar definida.

Além disso, como parece que você está mexendo com seu .Xauthorityarquivo, você pode excluí-lo totalmente, depois saia da sua sessão X e faça login novamente, para que o recrie automaticamente. Raramente é necessário mexer com o seu .Xauthority, portanto, tentar isso provavelmente é apenas uma medida desesperada que não ajudará.

O que você deve ver no lado local é:

$ echo $DISPLAY
:0.0

Em um sistema configurado corretamente, se você abrir um shell, não precisará configurá-lo manualmente, ele deverá ser herdado do ambiente que iniciou seu shell. No entanto, vi configurações do gerenciador de janelas / teclas de atalho que não tratam corretamente a herança de variáveis ​​de ambiente. Se você possui um sistema linux em execução gnome-sessionou kde-sessionque usa para iniciar seus shells ou scripts, suas variáveis ​​de ambiente da sessão X devem ser definidas corretamente, conforme descrito na documentação do Ubuntu sobre a herança de variáveis ​​de ambiente :

Quando um processo pai cria um processo filho, por exemplo, quando executamos o comando "gedit" no terminal e "bash" (o processo pai) cria "gedit" (o processo filho), o processo filho herda todas as variáveis ​​de ambiente e valores que o processo pai tinha.

...

Nota: no ambiente gráfico da área de trabalho do Gnome, o gnome-session é o processo pai de todos os processos em execução na área de trabalho. Esse fato (juntamente com o princípio da herança) é a chave para nossa capacidade de influenciar poderosamente a operação de nossa área de trabalho com variáveis ​​de ambiente. O processo equivalente no KDE é o kde-session.

ATUALIZADA

Obrigado por postar a saída de ssh -vvv. Nesse caso, a verbosidade extra de -vvvversus just -vé útil. A saída de depuração informa que o encaminhamento do X11 está sendo configurado corretamente:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Mas a :0primeira linha me leva a acreditar que ainda existe um erro de configuração no lado local na maneira como você está chamando o ssh. Em muitos sistemas, o valor padrão para DISPLAYé :0.0, não :0. Você está de alguma forma configurando o valor DISPLAYmanualmente manualmente antes de chamar o comando ssh?

Mais informações sobre o sistema local e como você está chamando o comando ssh seriam úteis neste momento.

• Forneça seu número de versão e distribuição do Linux.
• Você está usando um ambiente GNOME ou KDE padrão para o X ou algo mais que você personalizou?
• Você está chamando o ssh diretamente em uma linha de comando a partir de uma janela do terminal?
• Qual terminal você está usando? xterm, gnome-terminal ou?
• Como você iniciou o terminal em execução no ambiente X? De um menu? Tecla de atalho? ou?
• Você pode executar a xeyespartir da mesma janela do terminal em que a ssh -Xfalha?
• Você está chamando o comando ssh como o mesmo usuário em que você fez logon na sessão X?

Este último item é importante. Se você estiver executando o ssh como outro usuário (por exemplo, se você abriu uma janela do terminal raiz em vez de uma janela do terminal do usuário), encontrará esse problema mesmo se estiver configurando explicitamente, DISPLAY=:0pois não possui permissões para conecte-se ao servidor X por padrão como outro usuário (mesmo como root!)

Suas configurações parecem estar bem, mas tente "ssh -X home" como sugerido por Agemen.

Além disso, se tudo mais falhar, tente o seguinte:

Depois de enviar o shsh para a sua máquina doméstica, no tipo "casa":

xauth list

Em "trabalho", digite

xauth

O que fornecerá um prompt "xauth>". A partir daqui, digite "add" e copie e cole a saída da "lista xauth", uma linha por vez (cada linha precedida por "add"). Por exemplo:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Nos informe.

Não entendo claramente se você deseja exibir seus aplicativos remotos na tela local ( work) ou se deseja exibi-los no sistema remoto ( home).

No primeiro caso, acho que ssh -X hostdeveria ser suficiente, sem a necessidade de usar o xhost.

No segundo caso, o sistema em que você precisa usar o xhost é home, e não é suficiente, você também precisa exportar a variável de exibição.

xhost +work
export DISPLAY=:0.0

Não tenho muita certeza do que você quer fazer ... e como não sei quais diferenças existem entre o seu sistema e o meu, por um lado, e a configuração exata necessária para o seu caso, por outro lado (como Eu não sou um especialista ^ _ ^). Espero que ajude você de algumas maneiras, pois essas configurações também funcionaram para mim.