SSH X11 not working

Question

I have a home and work computer, the home computer has a static IP address.

If I ssh from my work computer to my home computer, the ssh connection works but X11 applications are not displayed.

In my /etc/ssh/sshd_config at home:

X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes 

At work I have tried the following commands:

xhost + home HOME_IP ssh -X home ssh -X HOME_IP ssh -Y home ssh -Y HOME_IP 

My /etc/ssh/ssh_config at work:

Host * ForwardX11 yes ForwardX11Trusted yes 

My ~/.ssh/config at work:

Host home HostName HOME_IP User azat PreferredAuthentications password ForwardX11 yes 

My ~/.Xauthority at work:

-rw------- 1 azat azat 269 Jun 7 11:25 .Xauthority 

My ~/.Xauthority at home:

-rw------- 1 azat azat 246 Jun 7 19:03 .Xauthority 

But it doesn't work

After I make an ssh connection to home:

$ echo $DISPLAY localhost:10.0 $ kate X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. kate: cannot connect to X server localhost:10.0 

I use iptables at home, but I've allowed port 22. According to what I've read that's all I need.

UPD. With -vvv

 ... debug2: callback start 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 debug2: client_session2_setup: id 1 debug2: fd 3 setting TCP_NODELAY debug2: channel 1: request pty-req confirm 1 ... 

When try to launch kate:

 debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 55486 debug2: fd 8 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug1: channel 2: new [x11] debug1: confirm x11 debug2: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug2: X11 rejected 2 i0/o0 debug2: channel 2: read failed debug2: channel 2: close_read debug2: channel 2: input open -> drain debug2: channel 2: ibuf empty debug2: channel 2: send eof debug2: channel 2: input drain -> closed debug2: channel 2: write failed debug2: channel 2: close_write debug2: channel 2: output open -> closed debug2: X11 closed 2 i3/o3 debug2: channel 2: send close debug2: channel 2: rcvd close debug2: channel 2: is dead debug2: channel 2: garbage collecting debug1: channel 2: free: x11, nchannels 3 debug3: channel 2: status: The following connections are open: #1 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1) #2 x11 (t7 r2 i3/0 o3/0 fd 8/8 cc -1) # The same as above repeate about 7 times kate: cannot connect to X server localhost:10.0 

UPD2 Please provide your Linux distribution & version number.
Are you using a default GNOME or KDE environment for X or something else you customized yourself?

 azat:~$ kded4 -version Qt: 4.7.4 KDE Development Platform: 4.6.5 (4.6.5) KDE Daemon: $Id$ 

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 ?

 From terminal emulator `yakuake` Manualy press `Ctrl + N` and write commands 

Can you run xeyes from the same terminal window where the ssh -X fails?

 `xeyes` - is not installed But `kate` or another kde app is running 

Are you invoking the ssh command as the same user that you're logged into the X session as?
From the same user

UPD3

I also download ssh sources, and using debug2() write why it's report that version is different
It see some cookies, and one of them is empty, another is MIT-MAGIC-COOKIE-1

Answer 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!

Answer 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!)

Answer 3

Your configs seem to be ok, but do try "ssh -X home" as Agemen suggested.

Also, if all else fails, try this:

After you ssh to your home machine from work, on "home" type:

xauth list 

Then, on "work", type

xauth 

Which will give you an "xauth>" prompt. From here, type "add", then copy paste the output of the "xauth list", one line at a time (each line prefaced by "add"). For example:

someguy@work:~$ xauth Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database xauth> add work/unix:0 MIT-MAGIC-COOKIE-1 781cc753194fd55ecdf6c4cf105c40e3 xauth> 

Let us know.

Answer 4

This solution worked on my MAC Running MacOS Monterey 12.2 Try this:

In the sshd_config file on the Linux server:

uncomment X11Forwarding and set it to yes on the SERVER

it should look like:

X11Forwarding yes 

DO NOT uncomment #X11DisplayOffet 10 DO NOT uncomment #X11UseLocalHost no

Run XQUARTZ on the MAC so that it opens a window on the MAC screen. DO NOT login using ssh in the XQUARTZ window.

Open a mac terminal window.

Login to your remote server on the MAC terminal, not the window XQUARTZ opened:

ssh -Y myusername@SERVER 

then run your X11 app from the MAC terminal NOT the open XQUARTZ window.

ex:

xclock & 

XQUARTZ will intercept the DISPLAY and show the app on the local e.g. terminal screen. If you export the DISPLAY to :0 the window will appear on the server side. Not what you probably want.

Answer 5

I don't understand clearly if you want to display your remote apps on your local display (work), or if you want to display them on the remote system (home).

In the first case, I think ssh -X host should be enough, without any need to use xhost.

In the second case, the system where you need to use xhost is home, and it is not enough, you need to export the display variable too.

xhost +work export DISPLAY=:0.0 

I'm not totally sure of what you want to do... and as I don't know what differences exist between your system and mine, on the first hand, and the exact configuration needed for you case on the other hand (as I'm not a specialist ^_^). Hope it will help you in some ways, as this too configurations have worked for me.