With SSH X11 forwarding (`ssh -X`), get `Can't open display` trying to run X applications

Question

I'm able to login to the server using:

ssh -X Hostip

but when I run the command xclock it gives me this error:

Error: Can't open display: localhost:11.0

I checked my display value using:

echo $DISPLAY

and the result is:

localhost:11.0

And X11 forwarding is set to YES in sshd_config file:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Do you have any advice what I'm missing here?

Answer 1

Use -Y. From the man page on ssh:

-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.

If you're still having problems though, you can try setting $DISPLAY to your local box's IP:

$ export DISPLAY='<ip_address>:11.0'

It may work to set it as

$ export DISPLAY='127.0.0.1:11.0'

People seem to have this problem commonly when ssh'ing from Mac OS X. You may also want to set

X11UseLocalhost no

in this case as well.

Answer 2

this worked for me:

Change

X11UseLocalhost yes

to

X11UseLocalhost no

Answer 3

Credit to https://unix.stackexchange.com/a/12772/61349 for their diagnostic instructions.

Ensure you're ssh client is requesting X11 Forwarding with the -v flag

ssh example.com -X -v

And look for thespecific message:

debug1: Requesting X11 forwarding with authentication spoofing.

Another telltail problem sign is the lack of the DISPLAY environment variable beign set for you. If its blank/unset, there is something wrong. At least according to the same post credited above, these variables are set for you automatically.

---

I was using an SSH Control Master my ssh connections like so:

Host <hostname>
    ControlMaster auto
    ControlPath ~/.ssh/control/%r@%h:%p
    ControlPersist 10m

My earlier ssh connection did not request X11Firwarding, therefore future ssh call's options weren't being used. So for me,

ssh -X was just being ignored altogether

If you aren't seeing "Requesting X11 Forwarding", but you do see the muxer reusing sessions;

debug1: auto-mux: Trying existing master
debug1: mux_client_request_session: master session id: 10

Then you need to exit your current ControlMaster for that connection and reconnect with the -X/-Y flag.

To Stop your ControlMaster

ssh -O check <hostname>

Master running (pid=2758)

(This will exit all active connections using the ControlMaster)

ssh -O exit <hostname>

Exit request sent.

Answer 4

What fixed this for me is simply installing xauth, once done it worked like a charm!

Answer 5

When trying to forward to XQuartz on macOS, I fixed the issue by running the ssh command (ssh -Y in my case) from the XQuartz terminal (opened by right-clicking the XQuartz icon in the dock and clicking Applications > Terminal).

Answer 6

Problem got fixed by installing "x11-server-utils" and reloading both sshd and my ssh session.

Answer 7

I faced similar problem - i was working on a remote server where i had to work with interactive plots and none of the above mentioned solutions worked for me.

I was using Ubuntu bash on Windows 10 and in the end installing Xming software (http://www.straightrunning.com/XmingNotes/) on Windows. There might be some configurations needed but I was finally able to work with plots on remote server. Just install and launch it (you can see its icon on the bottom tray), and run your graphical application again on the remote server (using the ssh session). Hope it helps!