Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question

4 Answers 4

up vote 6 down vote accepted

It not works because I have /etc/ssh/sshrc

End in sshd(8) writen next:

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

So I write in /etc/ssh/sshrc next commands (also from man):

        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!

share|improve this answer
    
You do it on the client or on the server side? –  alfonx Dec 16 '13 at 15:11
    
On a server side. (/etc/ssh/sshrc executed when client is connected) –  azat Dec 16 '13 at 21:00

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.

share|improve this answer
    
I have already tried ssh -X home (write in post). Yes I want to display remote apps on my local display. –  azat Jun 9 '11 at 17:51

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.

share|improve this answer
    
I have already tried ssh -X home (write in post). About xauth I will try tomorrow. –  azat Jun 9 '11 at 17:49
    
I try xauth list & xauth add, but still not works –  azat Jun 10 '11 at 8:58
    
I have add this record via xauth add azat/unix:10 MIT-MAGIC-COOKIE-1 ad01c582768c832ff591277b27863bc7 (because $DISPLAY=localhost:10.0), if this can help –  azat Jun 10 '11 at 9:13

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

share|improve this answer
    
Update question body –  azat Mar 6 '12 at 11:02
    
I added a new UPDATED section asking for more info to help debug this further. –  aculich Mar 6 '12 at 17:12
    
I don`t set DISPLAY manualy. In fact I think that I understand why it not works, because of X -nolisten on local machine –  azat Mar 6 '12 at 17:55
    
-nolisten has nothing to do with this problem. As far as X is concerned it knows nothing about your remote ssh connection. To X it looks like any other local program. –  aculich Mar 6 '12 at 18:22
1  
sshd can also be started in the foreground with extra verbosity in case the problem lies on the server-side. –  0xC0000022L Mar 6 '12 at 19:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.