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 ssh -Y para o meu Ubuntu 10.04 VM (rodando em VMware Fusion). Quando executo gedit .bashrc (por exemplo), obtenho:
(gedit:9510): Gtk-WARNING **: cannot open display:
set | grep DISPLAY não retorna nada.
Mas se eu ssh -Y na minha máquina Ubuntu 11.04, gedit .bashrc funciona. echo $DISPLAY retorna "localhost: 10.0".
Eu tentei export DISPLAY=localhost:10.0 enquanto fiz o ssh em minha VM e, em seguida, execute gedit .bashrc , 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 trabalha e a outra não?
Atualização: Conforme sugerido por Zoredache no comentário abaixo, eu corri sudo apt-get install xbase-clients , mas continuo com o mesmo problema.
Verifique o sshd_config do servidor (normalmente /etc/ssh/sshd_config ) e certifique-se de que a opção X11Forwarding esteja ativada com a linha
X11Forwarding yes
Se o X11Forwarding não for especificado, o padrão é não nas máquinas da Debian que eu tenho disponível para verificar.
De xhost +: Como corrigir o erro “Não é possível abrir o display” ao iniciar a GUI no servidor remoto :
Answer: You can fix the “cannot open display” error by following the xhost procedure mentioned in this article.
Allow clients to connect from any host using xhost+
Execute the following command to disable the access control, by which you can allow clients to connect from any host.
$ xhost +access control disabled, clients can connect from any host
Enable X11 forwarding
While doing ssh use the option -X to enable X11 forwarding.
$ ssh username@hostname -XEnable trusted X11 forwarding, by using the -Y option,
$ ssh username@hostname -YOpen GUI applications in that host
After opening ssh connection to the remote host as explained above, you can open any GUI application which will open it without any issue.
If you still get the “cannot open display” error, set the DISPLAY variable as shown below.
$ export DISPLAY='IP:0.0'Note: IP is the local workstation’s IP where you want the GUI application to be displayed.
Eu tive esse problema ao entrar em uma VM Ubuntu a partir do Mac OS X também - não parece gostar de 'localhost' na variável de exibição por algum motivo. Então defina o IP manualmente, como harrymc sugere:
export DISPLAY="127.0.0.1:10.0"
Então os programas X11 devem estar bem. Não parece que deveria ser necessário dizer ao SO que localhost e 127.0.0.1 são equivalentes, mas funciona, pelo menos.
Eu tive esse problema com o meu servidor CentOS KVM, estava faltando o programa "xauth".
Se você tiver esse problema após algum tempo ao executar com -X arg. ou apenas ForwardX11 em / etc / ssh / ssh_config, em seguida, execute $ ssh username@hostname -Y , para ativar o encaminhamento X11 confiável , não sei a causa exata, mas estou supondo que com -X alguns recursos expiram depois de algum tempo, provavelmente para aumentar a segurança.
Aqui está o que encontrei online:
If you use ssh -X remotemachine the remote machine is treated as an untrusted client. So your local client sends a command to the remote machine and receives the graphical output. If your command violates some security settings you'll receive an error instead.
But if you use ssh -Y remotemachine the remote machine is treated as trusted client. This last option can open security problems. Because other graphical (X11) client could sniff data from the remote machine (make screenshots, do keylogging and other nasty stuff) and it is even possible to alter those data.
If you want to know more about those things I suggest reading the Xsecurity manpage or the X Security extension spec. Furthermore you can check the options ForwardX11 and ForwardX11Trusted in your /etc/ssh/ssh_config.
fontes:
Ao executar o UXTERM ou o XTERM, apenas emita
export $DISPLAY
A variável estará lá. Em seguida, basta configurá-lo e exportá-lo.
Apenas testado no meu Mac, outros sistemas podem estar OK :
$ xhost +
[Mac System] Install X11 for mac https://www.xquartz.org/
update
/etc/ssh/sshd_configand setX11Forwarding yes, then restart your ssh server
-X
$ ssh -X user@ip
- open a ssh session that support X11 display(remember to keep this session)
- run
echo $DISPLAYin that ssh session- set
DISPLAYenvironment variable for your PyCharm
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
Eu tive que colocar /etc/ssh/sshd_config do seguinte:
X11UseLocalhost no
Em vez de definir "sim". Estranho se o padrão for "NÃO" Usuários usando massa com o XMing no Windows. Eu uso o ssh direto no Fedora. Ocasionalmente, começaria a nos dar
error can't open display localhost
A reinicialização do servidor normalmente corrige, mas isso é estúpido.
Fiz o acima, reiniciei o serviço sshd no servidor e pronto novas conexões funcionando bem novamente.
No CentOS 6.5, eu de repente perdi o acesso remoto aos programas X depois de mexer com / etc / hosts. O mesmo sintoma da variável $ DISPLAY vazia (não ajuda a definir / exportar manualmente).
A entrada 127.0.0.1 apontando para o nome do host atual é necessária; na verdade, a ordem parece ser também relevante (colocar por último e 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 consertar isso, xeyes, xclock e outros brinquedos de teste X estão funcionando novamente, portanto, o virt-manager necessário também está de volta à linha.
Acabei de encontrar um bom soluço na minha configuração que impediu o x encaminhamento: Meu firewall estava bloqueando todas as conexões do host local, impedindo assim que o túnel fosse alcançado
Se você estiver usando o Konsole, simplesmente mude para outro emulador de terminal como o Xfce Terminal e tente novamente usando root.
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.