Muitos já se depararam com uma mensagem dessas ao tentar abrir uma aplicação gráfica pelo terminal via ssh.
1 2 3 4 5 |
anjos:~ # ssh -X root@pitinga Password: Have a lot of fun... pitinga:~ # xclock Error: Can't open display: |
Numa busca rápida pelo google você encontra várias “soluções” que variam desde permissões dos arquivos do /etc, instalação do pacote xorg-x11-xauth, criação do arquivo .Xauthority no home do usuário, habilitar e desabilitar o controle de acesso com xhost + e xhost -, setar variável $DISPLAY com o comando export e por aí vai…
Falando em variável $DISPLAY, olha só o conteúdo dela (e mesmo alterando não consigo executar os aplicativos).
1 2 |
pitinga:~ # echo "->${DISPLAY}<- -> <- |
Mas e se nenhuma dessas soluções der certo?
Bem, comigo não resolveu e vou mostrar como acertei a configuração num OpenSuse 12.1 e um Debian 6.0.
Dei uma olhada no arquivo de log para obter mais informações. Destaquei apenas a mensagem de log que nos mostra o erro no ssh.
1 2 3 4 |
pitinga:~ # tail -f /var/log/messages ... Nov 7 14:02:52 sshd[992]: error: Failed to allocate internet-domain X11 display socket. ... |
Encontrei referências em http://bugs.debian.org e http://bugs.opensolaris.org (textos retirados de outros sites, pois a Oracle já não o mantém) sobre um problema com o openssh-server 5.5 quando o protocolo ipv6 era desabilitado.
Solução rápida, habilitar o ipv6 e pronto, realmente consegui executar minhas aplicações gráficas pelo terminal.
1 2 3 4 5 6 7 |
anjos:~ # ssh -X root@pitinga Password: Have a lot of fun... /usr/bin/xauth: file /root/.Xauthority does not exist pitinga:~ # echo $DISPLAY localhost:10.0 pitinga:~ # xclock |
Reparem que assim que realizo o ssh já recebo a informação de que o arquivo .Xauthority não existe, ou melhor, não existia porque o sistema acabou de criá-lo. Além disso, a variável $DISPLAY agora tem informação.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
pitinga:~ # ls -la /root/ total 68 drwx------ 12 root root 4096 Nov 7 14:02 . drwxr-xr-x 26 root root 4096 Nov 6 17:38 .. -rw------- 1 root root 61 Nov 7 13:18 .Xauthority -rw------- 1 root root 7407 Nov 7 14:02 .bash_history drwxr-xr-x 5 root root 4096 Nov 7 11:27 .config drwx------ 3 root root 4096 Sep 7 04:03 .dbus drwx------ 2 root root 4096 Nov 7 11:27 .gconf drwx------ 2 root root 4096 Sep 7 11:43 .gnupg drwxr-xr-x 2 root root 4096 Sep 7 03:40 .kbd drwxr-xr-x 3 root root 4096 Sep 7 04:03 .kde4 drwxr-xr-x 3 root root 4096 Sep 7 04:01 .kdm drwx------ 2 root root 4096 Sep 7 10:36 .ssh -rw------- 1 root root 4143 Nov 7 14:02 .viminfo drwxr-xr-x 2 root root 4096 Oct 25 2011 bin drwxr-xr-x 4 root root 4096 Sep 6 23:17 inst-sys pitinga:~ # |
Problema resolvido: Sim
Da maneira que eu queria: Não
Costumo desabilitar o protocolo ipv6 das máquinas onde sei que isso não será usado. Já tive algumas dores de cabeça por ele estar ativo, até escrevi um post junto com o Vagner Fonseca falando sobre isso “Módulos no Linux”.
Tem duas maneiras de utilizar o X11Forwarding do SSH sem problema e manter o ipv6 desativado, lembrando que as modificações foram feitas na máquina acessada.
-> Incluir o parâmetro “-4” na variável SSH_OPTS do arquivo /etc/sysconfig/ssh (OpenSuse) ou /etc/default/ssh (Debian) e reiniciar o serviço ssh.
OU
-> Descomentar o item #AddressFamily any no arquivo /etc/ssh/sshd_config, alterá-lo para AddressFamily inet e reiniciar o serviço ssh.
Espero que tenham gostado e até a próxima!