23

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?

Improve this question
3
  • 4
    In sshd_config you might need to set also: X11UseLocalhost no Commented Sep 13, 2019 at 12:16
  • Yes it will be work # ssh -Y server IP # xclock (working) Commented 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) Commented Jul 27, 2021 at 22:40

8 Answers 8

Reset to default
14

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.

Improve this answer
3
  • 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 Commented Jun 22, 2020 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! Commented Jan 12, 2024 at 19:16
  • -v pointed out quite clearly that I had forgotten to install xauth on the remote machine. Thank you. Commented Oct 25, 2024 at 19:36
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.

Improve this answer
2
  • Yes, I did. I actually found the problem and will post the solution shortly. Thank you for responding! Commented Jul 14, 2017 at 0:17
  • 2
    For more info on -X vs -Y, see askubuntu.com/a/35518/126830 Commented May 2, 2019 at 3:19
2

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
Improve this answer
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```
Improve this answer
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.

Improve this answer
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
Improve this answer
3
  • 1
    A particular option like ForwardX11, perhaps? Seems a bit much to move an otherwise useful file entirely aside. Commented 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 ... Commented Sep 19, 2019 at 11:19
  • 1
    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 Commented Jul 4, 2020 at 21:44
0

I had suffered the same problem, and I have solved removing the key from the client file $HOME/.ssh/known_hosts

So, next time it ask again if I trust in the host, and answer yes.

I discovered using ssh -X myhost-vvv, and after the warning about host key, I see the message saying that X11Forwarding was disabled.

Improve this answer
-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.

Improve this answer
1
  • 7
    It is not true, believe me it supports. If it won't work, ask a question about it. Commented Jun 5, 2018 at 19:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.