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?

  • In sshd_config you might need to set also: X11UseLocalhost no – user1708042 Sep 13 '19 at 12:16
  • Yes it will be work # ssh -Y server IP # xclock (working) – Gordhan Singh Rathore Jun 29 at 5:03

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 – Gearoid Murphy Jun 22 '20 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.


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 '19 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 ... – Sandro Weiser Sep 19 '19 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 '20 at 21:44

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.


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

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 '18 at 19:06

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.