I'm able to login to sever using

ssh -X Hostip

but when i run the command xclock it give me this error

Error: Can't open display: localhost:11.0

I check my Display value using


and the result is


And X11 forwarding is set to YES in sshd_config file

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Any advice what I'm missing here?

  • 3
    Have you tried -Y instead of -X?
    – Flup
    Jul 22 '13 at 11:35
  • 2
    Also, make sure you understand the implications of using -Y instead of -X. You may also want to look at xhost.
    – user
    Jul 22 '13 at 11:36
  • 1
    For RedHat/CentOS 7 (at least), you need the xorg-x11-xauth package, as per my answer here: unix.stackexchange.com/questions/138936/…
    – Mike S
    Apr 22 '16 at 20:12

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=''

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.

  • 1
    Using XQuartz I was unable to use the -Y flag. "X11 connection rejected because of wrong authentication."
    – Erik
    Feb 21 '14 at 4:01
  • 6
    even after trying your other suggestions, I'm unable to open a display.
    – Erik
    Feb 21 '14 at 4:04
  • 2
    Neither one of these worked for me either. I needed to install XWindow support in my Centos 7 server (minimal) with: yum groupinstall "X Window System" -y Dec 29 '15 at 16:19
  • @MarkEdington this is because RedHat/CentOS require the xorg-x11-xauth package, as per my answer here: unix.stackexchange.com/questions/138936/…
    – Mike S
    Apr 22 '16 at 20:11

this worked for me:


X11UseLocalhost yes


X11UseLocalhost no
  • Thanks, Don. that worked for me also. I gave you an upvote. I believe the problem interfering with the default was that the specific machine is xhost enabled. Dec 22 '15 at 0:21
  • 11
    on guest? host? which configuration file? thx to complete your answer Jul 20 '16 at 8:22
  • I made it to work by dropping the settings to /etc/ssh/sshd_config.
    – llinfeng
    Apr 29 '19 at 16:22
  • focal: Bad configuration option: x11uselocalhost
    – woodz
    Feb 19 at 17:38

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.

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


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

  • 1
    this worked for me
    – dli
    Sep 12 '19 at 21:10
  • The only way that worked for me too (instead of using iterm2). So this means it's a problem on the client (MacOS).
    – Phlogi
    Oct 10 at 12:55

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.