20

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?

secJ
  • 441
  • 1
  • 3
  • 9

7 Answers7

13

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.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
secJ
  • 441
  • 1
  • 3
  • 9
  • 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
  • While my underlining issue is different, the idea to start with -v to debug what causes the issue actually helped a lot! Thanks! – Alexander Kucheryuk Jan 12 '24 at 19:16
2

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.

Cory T
  • 181
1

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```
PaSe
  • 11
1

In my case, I am connecting from macOS Big Sur to Ubuntu 22.04 server. Everything was working super fine for months until today. Thanks to @secJ I was able to pinpoint my issue to this:

debug1: No xauth program.

I have XQuartz installed so I do have xauth client locally. Turns out I had to manually start XQuart on my Mac after which everything worked. Prior to this, SSH would automatically start xauth client, however, there was an update recently which might have changed something . Extra note, I do need this to make X server work fully:

export XAUTHORITY=$HOME/.Xauthority
Alexander Kucheryuk
  • 111
0

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
Sandro Weiser
  • 9
  • 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 04 '20 at 21:44
0

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.

user376449
  • 1
-4

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.

Boran
  • 3