18

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
  • 411
  • 1
  • 3
  • 9

6 Answers6

12

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
  • 55,929
  • 26
  • 146
  • 227
secJ
  • 411
  • 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
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
  • 5
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
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
  • 4
  • 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
  • 1
  • 1