Como posso corrigir um erro "cannot open display" quando abro um programa X após o ssh'ing com o X11 forwarding activado?

A partir de xhost+ : Como corrigir o erro “Cannot Open Display” durante o lançamento da GUI no servidor remoto :

Resposta : Pode corrigir o erro “Cannot Open Display” seguindo o procedimento xhost mencionado neste artigo.

Permitir que os clientes se liguem a partir de qualquer anfitrião utilizando xhost+

Executar o seguinte comando para desactivar o controlo de acesso, através do qual pode permitir que os clientes se liguem a partir de qualquer anfitrião.

$ xhost +

controlo de acesso desactivado, os clientes podem ligar-se a partir de qualquer anfitrião

Enable X11 forwarding

Enquanto faz ssh use a opção -X para activar o reencaminhamento X11.

$ ssh username@hostname -X

Habilitar reencaminhamento X11 fiável, utilizando a opção -Y,

$ ssh username@hostname -Y

Abrir aplicações GUI nesse anfitrião

Após abrir a ligação ssh ao anfitrião remoto como explicado acima, pode abrir qualquer aplicação GUI que a abra sem qualquer problema.

Se ainda assim obtiver o erro “cannot open display”, defina a variável DISPLAY como mostrado abaixo.

$ export DISPLAY='IP:0.0'

Nota: IP é o IP da estação de trabalho local onde pretende que a aplicação GUI seja mostrada.

Verifique o sshd_config do servidor (normalmente /etc/ssh/sshd_config), e certifique-se que a opção X11Forwarding está activada com a linha

X11Forwarding yes

Se o X11Forwarding não estiver especificado, o predefinido é não nas máquinas Debian que tenho disponíveis para verificar.

Tive este problema quando entrei numa VM Ubuntu do Mac OS X também – por alguma razão não parece gostar de ‘localhost’ na variável display. Então configure o IP manualmente, como sugere a Harrymc:

export DISPLAY="127.0.0.1:10.0"

Então os programas X11 devem ficar bem. Não parece ser necessário dizer ao SO que o localhost e 127.0.0.1 são equivalentes, mas funciona, pelo menos.

Eu tinha este problema com o meu servidor CentOS KVM, faltava-me o programa “xauth”.

Se tiver este problema após algum tempo quando correr com -X arg. ou apenas ForwardX11 em /etc/ssh/ssh_config, então corra $ ssh username@hostname -Y, para activar trusted X11 forwarding , não sei a causa exacta mas suponho que com -X algumas funcionalidades expiram após algum tempo, provavelmente para aumentar a segurança.

Aqui está o que encontrei online :

Se utilizar ssh -X remotemachine a máquina remota é tratada como um cliente não confiável. Então o seu cliente local envia um comando para a máquina remota e recebe a saída gráfica. Se o seu comando violar algumas definições de segurança receberá um erro.

Mas se utilizar o ssh -Y remotemachine a máquina remota é tratada como um cliente de confiança. Esta última opção pode abrir problemas de segurança. Porque outro cliente gráfico (X11) pode farejar dados da máquina remota (fazer capturas de ecrã, fazer keylogging e outras coisas desagradáveis) e até é possível alterar esses dados.

Se quiser saber mais sobre essas coisas sugiro que leia a manpage Xsecurity ou a especificação da extensão X Security. Além disso você pode verificar as opções ForwardX11 e ForwardX11Trusted no seu /etc/ssh/ssh_config.

fontes:

• qual é a diferença entre ssh -Y e ssh -X
• cygwin/X aviso: não foi possível abrir o X display

Só testado no meu Mac, outros sistemas podem ficar bem :

1. Permitir aos clientes ligarem-se a partir de qualquer anfitrião usando xhost+

$ xhost +

1. Deverá ter um ambiente que suporte o display X11

[Sistema Mac] Instalar X11 para mac https://www.xquartz.org/

1. Deverá deixar o seu servidor ssh encaminhar x11 display

actualizar /etc/ssh/sshd_config e definir X11Forwarding yes, depois reiniciar o seu servidor ssh

1. Deverá deixar a sua sessão ssh encaminhar x11 display com o parâmetro -X

$ ssh -X user@ip

1. Como abrir a aplicação X11 em PyCharm?

• abra uma sessão ssh que suporte o ecrã X11 (lembre-se de manter esta sessão)
• execute echo $DISPLAY nessa sessão ssh
• defina a variável de ambiente DISPLAY para o seu PyCharm

Tive de colocar no /etc/ssh/sshd_config o seguinte:

X11UseLocalhost no

Em vez de o definir “sim”. Estranho se a predefinição for “NÃO” Utilizadores que utilizam putty com XMing no Windows. Eu uso ssh direto sobre o Fedora. Ocasionalmente começava a dar-nos

error can't open display localhost

A reinicialização do servidor normalmente corrigi-lo, mas isto é estúpido. Fiz o acima referido, reiniciei o serviço sshd no servidor e pré-conexões novas funcionam bem novamente.

Ao executar UXTERM ou XTERM basta emitir

export $DISPLAY

A variável estará lá. Depois é só defini-la e exportá-la.

Esta configuração funciona para mim:

Local (64 bit Cygwin no Windows 10) DISPLAY=:0

Server (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

Estas configurações foram encontradas clicando em “X menu de aplicações em :0” na barra de tarefas e seleccionando Ferramentas do Sistema > Terminal

Também tive este problema com o Solaris 10 e descobri que o ouvinte não foi criado.

svccfg –s /application/x11/x11-server listprop options/tcp_listen
svccfg –s /application/x11/x11-server setprop options/tcp_listen = true

Se você estiver usando o Konsole simplesmente mude para outro emulador de terminal como o Xfce Terminal e tente novamente usando a raiz.

No CentOS 6.5, perdi subitamente o acesso aos programas X remotos depois de me ter metido com o /etc/hosts. O mesmo sintoma de variável $DISPLAY vazia (sem ajuda na configuração/exportação manual).

A entrada 127.0.0.1 apontando para o verdadeiro nome da máquina é necessária; de facto a ordem também parece ser relevante (colocar por último & não vai funcionar…)

[root@poseidon /etc]$ cat hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
127.0.0.1 poseidon.mycampus.edu poseidon
1XX.XXX.XXX.208 poseidon.mycampus.edu poseidon

Depois de corrigir isto, xeyes, xclock e outros brinquedos de teste X estão a funcionar novamente, portanto o meu virt-manager necessário também está de novo em linha.

Acabei de encontrar um belo soluço na minha configuração que impediu o x encaminhamento: A minha firewall estava a bloquear todas as ligações a partir do local, impedindo assim que o túnel fosse alcançado.

terminal aberto $ ssh username@hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY=“127.0.0.1:10.0” tudo deve funcionar.