Bdtyktl

From xhost+ : How to Fix “Cannot Open Display” Error While Launching GUI on Remote Server:

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 -X

Enable trusted X11 forwarding, by using the -Y option,

$ ssh username@hostname -Y

Open 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.

I've had this problem when logging into a Ubuntu VM from Mac OS X as well -- it doesn't seem to like 'localhost' in the display variable for some reason. So set the IP manually, as harrymc suggests:

export DISPLAY="127.0.0.1:10.0"

Then X11 programs should be fine. It doesn't seem like it should be necessary to tell the OS that localhost and 127.0.0.1 are equivalent, but it works, at least.

I had this problem with my CentOS KVM server, I was missing the "xauth" program.

If you have this problem after some time when running with -X arg. or just ForwardX11 in /etc/ssh/ssh_config, then run $ ssh username@hostname -Y, to enable trusted X11 forwarding, don't know the exact cause but I'm guessing with -X some features expire after some time, probably to increase security.

Here is what I found 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.

sources:

• what is the difference between ssh -Y and ssh -X


• cygwin/X warning: could not open X display

When running UXTERM or XTERM just issue

export $DISPLAY 

The variable will be there. Then just set it and export it.

Just Tested On My Mac, Other Systems Might Be OK:

1. Allow clients to connect from any host using xhost+
   
   

   
   

   $ xhost +

   
   

   
   


2. You should have an environment that support X11 display
   
   

   
   

   [Mac System] Install X11 for mac https://www.xquartz.org/

   
   

   
   


3. You should let your ssh-server forward x11 display
   
   

   
   

   update /etc/ssh/sshd_config and set X11Forwarding yes, then restart your ssh server

   
   

   
   


4. You should let your ssh session forward x11 display with -X parameter
   
   

   
   

   $ ssh -X user@ip

   
   

   
   


5. How to open X11 app in PyCharm?
   
   

   
   

   
   
   • open a ssh session that support X11 display(remember to keep this session)
   
   
   • run echo $DISPLAY in that ssh session
   
   
   • set DISPLAY environment variable for your PyCharm
   
   

   
   

   
   

I also had this problem with Solaris 10 and found that the listener was not set up.

svccfg –s /application/x11/x11-server listprop options/tcp_listen

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

I had to put in /etc/ssh/sshd_config the following:

X11UseLocalhost no

Rather then setting it "yes". Strange if the default is "NO"
Users using putty with XMing under Windows.
I use straight ssh over Fedora.
Occasionally it would start giving us

error can't open display localhost

Reboot of the server would usually fix it but this is stupid.
Did the above, restarted the service sshd on the server and presto new connections working fine again.

On CentOS 6.5, I suddenly lost remote X-programs access after messing with /etc/hosts.
Same symptom of empty $DISPLAY variable (no help setting/exporting it manually).

The 127.0.0.1 entry pointing to the actual hostname is necessary; in fact the order seems to be also relevant (put last & it won't work...)

[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

After fixing this, xeyes, xclock and other X test toys are working again, therefore my needed virt-manager is also back on line.

I just found a nice hiccup in my setup that prevented x forwarding:
My firewall was blocking all connections from localhost, thus preventing the tunnel to be reached

If you happen to be using Konsole simply switch to another terminal emulator such as Xfce Terminal and try again using root.

open terminal
$ ssh username@hostname -X

$ ssh username@hostname -Y



$ export DISPLAY='IP:0.0'

export DISPLAY="127.0.0.1:10.0"
all should work.

After a lot of frustration I found out that the entry for the hostname of the server in his /etc/host file was incorrect.