SSH X11 not working

Solution 1:

The reason ssh X forwarding wasn't working was because I have a /etc/ssh/sshrc config file.

The end of the sshd(8) man page states:

If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth

So I add the following commands to /etc/ssh/sshrc (also from the sshd man page) on the server side:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

And it works!

Solution 2:

Any time you're having trouble with ssh, the first thing you should do is run the client with the -v option to provide that output for others to inspect:

ssh -v user@somewhere

I am going to guess that the problem is on your local system. How are you invoking the ssh command? Are you running it manually in a shell? Or is it being executed as part of a script? In either case you'll want to make sure that your local system has the DISPLAY environment set correctly. It also needs to be set correctly on the remote side, as well, but that value will be different on the remote side than the local side.

From what you wrote it seems that it is being set correctly on the remote host (and by extension the X11 forwarding is being set up correctly by ssh). On the remote system you have:

$ echo $DISPLAY
localhost:10.0

What is that showing on the local side? That should be easy to check if you're in a shell both by echoing the value, as well as starting an X app from that shell... you can always use the venerable xeyes for that kind of testing, of course! :)

On the other hand, if you are invoking the ssh command from a script or attached to a hotkey it might not inherit the environment that you expect, so DISPLAY environment variable on the local side might not be set at all.

Also, since it sounds like you've been fiddling with your .Xauthority file you may want to delete it entirely, then log out of your X session and log back in so it will automatically re-create it. There is rarely a need to muck with your .Xauthority, so trying that is likely just a desperate measure that won't help.

What you should see on the local side is:

$ echo $DISPLAY
:0.0

On a properly configure system if you open a shell you shouldn't need to set it by hand, it should get inherited from the environment that started your shell. However I have seen window manager / hotkey configs that do not properly handle environment variable inheritance. If you have linux system running gnome-session or kde-session that you use to launch your shells or scripts from, then your X session environment variables should get set correctly as described in the Ubuntu documentation about inheritance of environment variables:

When a parent process creates a child process, for example when we run the "gedit" command from the terminal and "bash" (the parent process) creates "gedit" (the child process), the child process inherits all the environment variables and values the parent process had.

...

Note: in the Gnome graphical desktop environment, gnome-session is the parent process of all the processes running on the desktop. This fact (along with the Inheritance principle) is the key to our ability to powerfully influence the operation of our desktop with environment variables. The equivalent process in KDE is kde-session.

UPDATED

Thanks for posting the output from ssh -vvv. In this case the extra verbosity from -vvv versus just -v is helpful. The debug output tells me that X11 forwarding is being set up correctly:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

But the :0 in the first line leads me to believe there is still a configuration error on the local side in the way you're invoking ssh. On many systems the default value for DISPLAY is :0.0, not :0. Are you somehow setting the value of DISPLAY manually yourself before invoking the ssh command?

More information about your local system and how you're invoking the ssh command would be helpful at this point.

• Please provide your Linux distribution & version number.
• Are you using a default GNOME or KDE environment for X or something else you customized yourself?
• Are you invoking ssh directly on a command line from a terminal window?
• What terminal are you using? xterm, gnome-terminal, or?
• How did you start the terminal running in the X environment? From a menu? Hotkey? or ?
• Can you run xeyes from the same terminal window where the ssh -X fails?
• Are you invoking the ssh command as the same user that you're logged into the X session as?

This last item is important. If you're running ssh as another user (for example, if you opened up a root terminal window instead of a user terminal window), then you'll encounter this problem even if you are explicitly setting DISPLAY=:0 since you don't have permissions to connect to the X server by default as another user (even as root!)