Como corrijo um erro de "não é possível abrir a tela" ao abrir um programa X após o ssh'ing com o encaminhamento X11 ativado?

Depois de iniciar o aplicativo X11 (XQuartz 2.3.6, xorg-server 1.4.2-apple56) no meu Mac (OS X 10.6.8), abrindo um terminal no X11 e executando xhost +, eu então vou ssh -Ypara a minha VM Ubuntu 10.04 (executando no VMware Fusão). Quando corro gedit .bashrc(por exemplo), recebo:

(gedit:9510): Gtk-WARNING **: cannot open display: 

set | grep DISPLAY não retorna nada.

Mas se eu ssh -Yentrar na minha máquina Ubuntu 11.04, gedit .bashrcfunciona. echo $DISPLAYretorna "localhost: 10.0".

Tentei export DISPLAY=localhost:10.0enquanto sshed na minha VM e, em seguida gedit .bashrc, executando , mas recebo:

(gedit:9625): Gtk-WARNING **: cannot open display: localhost:10.0

O que poderia ser diferente na configuração das duas máquinas Ubuntu diferentes que explicariam por que uma funciona e a outra não?

Atualização: conforme sugerido por Zoredache no comentário abaixo, executei sudo apt-get install xbase-clients, mas continuo tendo o mesmo problema.

Verifique o sshd_config do servidor (normalmente /etc/ssh/sshd_config) e verifique se a opção X11Forwarding está ativada com a linha

X11Forwarding yes

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

Do xhost +: Como corrigir o erro "Não é possível abrir a tela" ao iniciar a GUI no servidor remoto :

Resposta : Você pode corrigir o erro "não é possível abrir a tela" seguindo o procedimento xhost mencionado neste artigo.

Permitir que os clientes se conectem a partir de qualquer host usando xhost +

Execute o seguinte comando para desativar o controle de acesso, pelo qual você pode permitir que os clientes se conectem a partir de qualquer host.

$ xhost +

controle de acesso desabilitado, os clientes podem se conectar de qualquer host

Ativar encaminhamento X11

Ao fazer o ssh, use a opção -X para ativar o encaminhamento do X11.

$ ssh username@hostname -X

Ative o encaminhamento confiável do X11, usando a opção -Y,

$ ssh username@hostname -Y

Aplicativos GUI abertos nesse host

Após abrir a conexão ssh com o host remoto, conforme explicado acima, você pode abrir qualquer aplicativo GUI que o abra sem nenhum problema.

Se você ainda receber o erro "não é possível abrir a tela", defina a variável DISPLAY como mostrado abaixo.

$ export DISPLAY='IP:0.0'

Nota: IP é o IP da estação de trabalho local onde você deseja que o aplicativo GUI seja exibido.

Eu tive esse problema ao fazer login em uma VM do Ubuntu a partir do Mac OS X - ele não parece 'localhost' na variável de exibição por algum motivo. Portanto, defina o IP manualmente, como sugere o harrymc:

export DISPLAY="127.0.0.1:10.0"

Os programas X11 devem ficar bem. Não parece ser necessário informar ao sistema operacional que localhost e 127.0.0.1 são equivalentes, mas funciona, pelo menos.

Eu tive esse problema com meu servidor CentOS KVM, estava faltando o programa "xauth".

Se você tiver esse problema após algum tempo ao executar com -Xarg. ou apenas ForwardX11em / etc / ssh / ssh_config e execute $ ssh username@hostname -Y, para habilitar o encaminhamento confiável do X11 , não sei a causa exata, mas acho que -Xalguns recursos expiram após algum tempo, provavelmente para aumentar a segurança.

Aqui está o que eu encontrei online:

Se você usar a máquina remota ssh -X, a máquina remota será tratada como um cliente não confiável. Portanto, seu cliente local envia um comando para a máquina remota e recebe a saída gráfica. Se o seu comando violar algumas configurações de segurança, você receberá um erro.

Mas se você usar a máquina remota ssh -Y, a máquina remota será tratada como cliente confiável. Esta última opção pode abrir problemas de segurança. Como outro cliente gráfico (X11) pode farejar dados da máquina remota (fazer capturas de tela, fazer keylogging e outras coisas desagradáveis) e é ainda possível alterar esses dados.

Se você quiser saber mais sobre essas coisas, sugiro ler a página de manual do Xsecurity ou a especificação de extensão do 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
• aviso cygwin / X: não foi possível abrir a tela X

Apenas testado no meu Mac, outros sistemas podem estar OK :

1. Permitir que os clientes se conectem a partir de qualquer host usando xhost +

   $ xhost +

2. Você deve ter um ambiente que suporte a exibição X11

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

3. Você deve deixar o servidor ssh encaminhar a exibição x11

   atualize /etc/ssh/sshd_confige defina X11Forwarding yese reinicie o servidor ssh

4. Você deve deixar sua sessão ssh encaminhar x11 com o -Xparâmetro

   $ ssh -X usuário @ ip

5. Como abrir o aplicativo X11 no PyCharm?

   • abra uma sessão ssh que suporte a exibição X11 (lembre-se de manter esta sessão)
   • executar echo $DISPLAYnessa sessão ssh
   • definir DISPLAYvariável de ambiente para o seu PyCharm

Ao executar UXTERM ou XTERM, basta emitir

export $DISPLAY 

A variável estará lá. Em seguida, basta configurá-lo e exportá-lo.

Eu tive que colocar /etc/ssh/sshd_configo seguinte:

X11UseLocalhost no

Em vez disso, defina-o como "sim". Estranho se o padrão for "NÃO" Usuários usando massa com XMing no Windows. Eu uso ssh direto sobre o Fedora. Ocasionalmente, começava a nos dar

error can't open display localhost

A reinicialização do servidor geralmente o corrigia, mas isso é estúpido. Feito isso, reiniciei o serviço sshdno servidor e presto novas conexões funcionando novamente.

Eu também tive esse problema com o Solaris 10 e descobri que o ouvinte não estava configurado.

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

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

A entrada 127.0.0.1 apontando para o nome do host real é necessária; de fato, a ordem também parece ser relevante (coloque por último e não 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 consertar isso, xeyes, xclock e outros brinquedos de teste X estão funcionando novamente, portanto, meu virt-manager necessário também está de volta à linha.

Acabei de encontrar um bom soluço na minha configuração que impedia o encaminhamento de x: Meu firewall estava bloqueando todas as conexões do host local, impedindo o acesso ao túnel

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

terminal aberto $ ssh username @ hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

exportar DISPLAY = "127.0.0.1:10.0" tudo deve funcionar.

Essa configuração funciona para mim:

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

Servidor (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

Essas configurações foram encontradas clicando em "X menu de aplicativos em: 0" na barra de tarefas e selecionando Ferramentas do Sistema> Terminal

Depois de muita frustração, descobri que a entrada para o nome do host do servidor em seu arquivo / etc / host estava incorreta.