Sempre que tiver problemas com o ssh, a primeira coisa que você deve fazer é executar o cliente com a opção -v para fornecer a saída a ser inspecionada por outras pessoas:
ssh -v user@somewhere
Vou adivinhar que o problema está no seu sistema local. Como você está invocando o comando ssh? Você está executando manualmente em um shell? Ou está sendo executado como parte de um script? Em ambos os casos, você desejará certificar-se de que seu sistema local tenha o ambiente DISPLAY configurado corretamente. Ele também precisa ser configurado corretamente no lado remoto, mas esse valor será diferente no lado remoto do que no lado local.
A partir do que você escreveu, parece que 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 mostrando no lado local? Isso deve ser fácil de verificar se você está em um shell fazendo eco ao valor, bem como iniciando um aplicativo X a partir desse shell ... você sempre pode usar o venerable xeyes para esse tipo de teste, é claro! :)
Por outro lado, se você estiver chamando o comando ssh de um script ou conectado a uma tecla de atalho, ele pode não herdar o ambiente esperado, portanto, DISPLAY variável de ambiente no lado local pode não ser definido.
Além disso, já que parece que você está mexendo no arquivo .Xauthority , você pode querer deletá-lo completamente, então saia da sua sessão X e faça o login novamente para que ele seja recriado automaticamente. Raramente há a necessidade de mexer com o seu .Xauthority , então tentar isso é provavelmente apenas uma medida desesperada que não vai ajudar.
O que você deve ver no lado local é:
$ echo $DISPLAY
:0.0
Em um sistema configurado adequadamente, se você abrir um shell, não precisará configurá-lo manualmente; ele deverá ser herdado do ambiente que iniciou o shell. No entanto, eu tenho visto configurações de gerenciador de janelas / teclas de atalho que não manipulam adequadamente a herança de variáveis de ambiente. Se você tem o sistema linux executando gnome-session ou kde-session que você usa para iniciar seus shells ou scripts, então suas variáveis de ambiente da sessão X devem ser configuradas corretamente como descrito no Documentação do Ubuntu sobre herança de variáveis de ambiente :
When a parent process creates a child process, for example when we run
the "gedit" command from the terminal and "bash" (the parent process)
creates "gedit" (the child process), the child process inherits all
the environment variables and values the parent process had.
...
Note: in the Gnome graphical desktop environment, gnome-session is the
parent process of all the processes running on the desktop. This fact
(along with the Inheritance principle) is the key to our ability to
powerfully influence the operation of our desktop with environment
variables. The equivalent process in KDE is kde-session.
ATUALIZADO
Obrigado por postar a saída de ssh -vvv . Nesse caso, o detalhamento extra de -vvv versus apenas -v é útil. A saída de depuração me diz 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 o :0 na primeira linha me faz acreditar que ainda existe um erro de configuração no lado local na maneira como você está invocando o ssh. Em muitos sistemas, o valor padrão para DISPLAY é :0.0 , não :0 . De alguma forma você está definindo o valor de DISPLAY manualmente antes de chamar o comando ssh?
Mais informações sobre o seu sistema local e como você está invocando o comando ssh seriam úteis neste momento.
- Por favor, forneça sua distribuição Linux & número da versão.
- Você está usando um ambiente GNOME ou KDE padrão para X ou algo mais que você mesmo personalizou?
- Você está chamando o ssh diretamente em uma linha de comando a partir de uma janela de terminal?
- Qual terminal você está usando? xterm, gnome-terminal ou?
- Como você iniciou o terminal em execução no ambiente X? De um menu? Hotkey ou?
- Você pode executar
xeyes da mesma janela do terminal em que ssh -X falha?
- Você está invocando o comando ssh como o mesmo usuário que você está conectado na sessão X como?
Este último item é importante. Se você estiver executando o ssh como outro usuário (por exemplo, se você abriu uma janela de terminal raiz em vez de uma janela de terminal do usuário), você encontrará esse problema mesmo se estiver definindo explicitamente DISPLAY=:0 , pois não tem permissões para se conectar ao servidor X por padrão como outro usuário (mesmo como root!)