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?


111

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.


2
A caixa Ubuntu 10.04 possui as ferramentas adequadas para o X11 instaladas? Instale xbase-clients, se já não estiver instalado.
Zoredache

Eu instalei, mas ainda tenho o mesmo problema. (Veja acima).
Daryl Spitzer

3
Talvez tente passar a opção -vv para ssh ao se conectar, isso imprime mensagens de depuração detalhadas; você deve ver vários comentários sobre o encaminhamento do X11 durante a conexão.
Zoredache

1
@jcrawfordor Você checou X11Forwardingo ubuntu e xbase-clientsinstalou e pode iniciar o Xapps no mac no terminal do qual está fazendo a conexão ssh. (Verifique se $DISPLAYestá definido no terminal de executar ssh a partir .
Manwe

1
No meu caso, era apenas uma questão de atualizar a versão XQuartz do MacOS
Waruna Ranasinghe

Respostas:


47

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.


4
Descobri depois de configurar outra VM do Ubuntu, que preciso instalar o xbase-clients e ativar o X11Forwarding. Atualize sua resposta para incluir as duas e eu a aceito.
Daryl Spitzer

1
Interessante. Pelo menos na nova instalação do 10.04 que fiz esta manhã, o X11Forwarding foi ativado por padrão. Os caras do Ubuntu devem estar brincando com os padrões novamente.
Zoredache

28
@DerfK, no meu sistema "X11Forwarding yes" já estava lá, estou recebendo erro como, (gedit: 8381): Gtk-WARNING **: não pode abrir a tela: nesses casos
AJ

1
No Debian, você pode ter que instalar o pacote xauth e depois logar novamente.
comte

$ ssh username @ hostname -Y isso funcionou para mim
MarcoZen 31/07

60

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.


11
+1 para a nota que IP = é o IP da estação de trabalho local onde você deseja obter a GUI
PCoder

3
Para aqueles com problemas semelhantes no OS X, verifique também se o XQuartz está instalado, caso contrário nenhuma dessas correções ajuda. (Pergunta de OP mostra que ele tem XQuartz, por isso esta é mais uma nota lado para aqueles que têm problemas semelhantes como eu estava)
Dolan Antenucci

3
Observe que a execução xhost +é muito insegura e não deve ser usada! Como Stefan Rogin mencionou, o invasor pode se conectar ao seu XSession, ler tudo o que você digita ou até alterar a tela que vê.
Jirislav #

o último export Display=IP:0.0fez isso por mim
javadba 18/10

18

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.


Isso funcionou para mim. Alguma idéia de por que o host local não estava funcionando?
24413 Alex

2
BINGO! Estou com esse problema há algum tempo ... Conectei-me pelo SSH e não consegui iniciar programas Gtk (o X11 simples, como "xeyes", funcionava no entanto). DISPLAY estava correto. Na verdade, a resolução do "localhost" não foi! Se eu definir manualmente DISPLAY = 127.0.0.1: 10.0 ou DISPLAY = :: 1: 10.0, ele funcionará. A edição de / etc / hosts parece não ter efeito; e o DNS está configurado corretamente (o "dig localhost" corrige 127.0.0.1 e :: 1) Portanto, parece ser um bug em qualquer resolução de DNS para conexões X11 no Gtk (gtk? gdk? glib? other?).
Pablo Saratxaga

1
Em uma instalação Debian para o Beagle Bone Black, o / etc / host não foi definido como legível por ninguém além do root. Isso causou os sintomas relatados aqui. Tornou o / etc / hosts legível por todos e funcionou bem.
Daniel

13

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


1
Isso me ajudou na minha instalação mínima do debian, muito obrigado!
binOr

9

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:


6

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

1
Por que isso é diferente ou por que deveria ser preferido em relação a qualquer outra resposta? Por favor, explique se você puder com uma edição simples . Você consegue!!
Pimp Juice IT

@ McDonald's Thanks, atualizado com mais detalhes.
Color

4

Ao executar UXTERM ou XTERM, basta emitir

export $DISPLAY 

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


4

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.


2

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

1

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.


1

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


1

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


1

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.


Obrigado. Funciona para o meu caso especial quando DISPLAY='localhost:10.0'não está funcionando.
xpt

1

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


0

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.