I am running CentOS/RHEL 6 and having the same issues as described in the referenced question below.

I have tried all of the settings suggested in this almost identical question, but to no avail.

On the server-side I have the following sshd_config settings: X11Forwarding yes X11DisplayOffset 10

xauth is installed on the server, and after successfully connecting over SSH I do get a MAGIC-COOKIE in ~/.Xauthority. I do not get any xauth related errors.

When I ssh in using -X (and add verbosity for troubleshooting -vvv), I successfully connect. When I try to run xclock it fails with an error of "Can't open display: localhost:10.0". This is a STDOUT error and not an error from the ssh -vvv. I do NOT receive any failed X11 attempts in ssh.

Then I try to verify the $DISPLAY variable, but get no output (it's not set).

It there some other setting somewhere that sets $DISPLAY properly? In this particular case, I can force the setting export DISPLAY=localhost:10.0, which then returns correctly after running echo $DISPLAY. Unfortunately, I still do NOT get any X-Windows program (e.g., xlcock) to come back. I still get the "Can't open display: localhost:10.0" error.

I'm at a loss. Any suggestions? Anything else that can set $DISPLAY during an SSH session?

  • 4
    In sshd_config you might need to set also: X11UseLocalhost no Sep 13, 2019 at 12:16
  • Yes it will be work # ssh -Y server IP # xclock (working) Jun 29, 2021 at 5:03
  • 2
    For future reference, @user1708042's comment here was the issue for me (X11UseLocalhost no in sshd_config fixed this issue on my machine)
    – ifconfig
    Jul 27, 2021 at 22:40

6 Answers 6


Turns out the guidance here is correct.

However, I did run into a unique issue that may help others. I started troubleshooting with -vvv and because there was so much data, I missed a critical warning (lesson learned is to start broader (-v)). The host key for the server changed (new build) and I disabled key checking in my ssh_config, so because it was a mismatched key X11 forwarding was disabled by SSH.

  • Just running with -vvv was enough to expose the underlying issue which was the fact that I didn't have a DISPLAY variable set in the local environment Jun 22, 2020 at 22:16

Have you tried using ssh -Y to connect? It appears X11 forwarding still isn't happening and you're it attempts to run remote X programs locally instead of remotely using your local display.


X11DisplayOffset seems to cause the blockage.

X11Forwarding yes       # < You only need this one.

# X11DisplayOffset 10   # < comment it out here
# X11UseLocalhost no     

Compression yes         # < helps with transmission of data```

For me, I had the same issue but the suggestions were already done before I installed X11. Turns out the issue was that I forgot to log off and back on after installing X11. Just in case anyone else had that same brain fart.


Maybe some options set in ~/.ssh/config prevent X forwarding from working, so temp move the file out of way:

mv ~/.ssh/config ~/.ssh/config.backup
  • A particular option like ForwardX11, perhaps? Seems a bit much to move an otherwise useful file entirely aside.
    – Jeff Schaller
    Sep 18, 2019 at 18:00
  • @JeffSchaller I don't want to fiddle out all possible options in .ssh/config which can prevent X11 forwarding from working. Moving the file out of the way and using ssh -X worked for me, after this you can still fiddle out options in .ssh/config ... Sep 19, 2019 at 11:19
  • This was my problem - thanks! However, I very strongly recommend that you do not put this file in /tmp/ because you will lose it on reboot. I opted for mv ~/.ssh/config ~/.ssh/config.bak
    – sage
    Jul 4, 2020 at 21:44

I met the same problem. I solved it by switching ssh client from OpenSSH to Putty. It seems that OpenSSH does not support x11 forwarding.

  • 6
    It is not true, believe me it supports. If it won't work, ask a question about it.
    – peterh
    Jun 5, 2018 at 19:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .