X forwarding through SSH

[at]

I am trying to forward X server to a remote computer (execute applications on a remote computer while displaying the GUI on a local one).

I login into the remote computer as:

ssh -Y -vvv -l <remote user> <remote host>

The login is successful and I can see the following message:

debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 38400

However, when I try to execute xclock on the remote machine, I get:

debug2: tcpwinsz: 87380 for connection: 3
debug1: client_input_channel_open: ctype x11 rchan 2 win 87380 max 16384
debug1: client_request_x11: request from 127.0.0.1 53369
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: tcpwinsz: 87380 for connection: 3
debug2: tcpwinsz: 87380 for connection: 3
debug2: tcpwinsz: 87380 for connection: 3
debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: write failed
debug2: channel 1: close_write
debug2: channel 1: output open -> closed
debug2: X11 closed 1 i3/o3
debug2: channel 1: send close
debug2: tcpwinsz: 87380 for connection: 3
debug2: channel 1: rcvd close
debug2: tcpwinsz: 87380 for connection: 3
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
#1 x11 (t7 r2 i3/0 o3/0 fd 7/7 cfd -1)

debug3: channel 1: close_fds r 7 w 7 e -1 c -1
debug2: tcpwinsz: 87380 for connection: 3

I can see that no xauthfile file has been created on the remote machine:

# ls -l /tmp/ssh-ONrDZb6334
ls: cannot access /tmp/ssh-ONrDZb6334: No such file or directory

And when I try to create xauthfile nmanually, I get an error:

# mkdir /tmp/ssh-ONrDZb6334
# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":0.0".

or

# echo $DISPLAY
localhost:11.0
# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :11.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":11.0".

I have X11Forwarding yes set in /etc/ssh/sshd_config and don't see anything relevant in the log files.

Any ideas???

[bunder]

connecting with -X is what enables the X forwarding on the client side.

cheers

[notHerbert]

Did you try running

Code: Select all

xhost +<local host>

on the remote host ?

[reavertm]

Did you try running

Code: Select all

xhost +<local host>

on the remote host ?

Doesn't it work the opposite way?
I mean to run it at localhost, specifying remote host, or just

Code: Select all

xhost +

making remote host able to connect to local X server and use it's display.

[notHerbert]

Doesn't it work the opposite way?
I mean to run it at localhost, specifying remote host, or just

Code: Select all

xhost +

making remote host able to connect to local X server and use it's display.

When I do an Xnest then the Remote host needs the ACL. This may be different though. Try it this way and then the other way.

Code: Select all

xhost + # to add ACL 
xhost - # remove ACL

I wouldn't do "xhost +" without specifying a hostname, "xhost +user@host" is more secure.

[at]

According to ssh manual, X forwarding is achieved by using either -X or -Y. I get the same results (described in the original posting) with both.

I did execute xhost on the local machine (the one that runs X server). That worked without a problem:

# xhost +
access control disabled, clients can connect from any host
# xhost
access control disabled, clients can connect from any host

However, that does not help.

In my opinion, SSH X forwarding relies on MIT cookie authentication. From the log I can see that SSH server is attempting to create a cookie upon a login:

debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.

As you can see, no cookies are created. (I have also manually verified.)

When I try to create a cookie manually (on the remote machine), I get an error:

# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":0.0".
# echo $DISPLAY
localhost:11.0
# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :11.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":11.0".

Do you know why is is failing to create a cookie?

[notHerbert]

When I try to create a cookie manually (on the remote machine), I get an error:

# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":0.0".
# echo $DISPLAY
localhost:11.0
# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :11.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":11.0".

Do you know why is is failing to create a cookie?

I think that is precisely why the remote host needs ACL for local machine, therefore my 1st suggestion is probably correct.
There is another potential problem. If you login to X through xdm/kdm/gdm you probably have -nolisten tcp enabled (by default). Test like this

Code: Select all

ps wax | grep X

If you see -nolisten tcp, then change that in the *dm config files eg. /usr/kde/3.5/share/config/kdm/kdmrc, /etc/X11/gdm/custom.conf.

[Mad Merlin]

When I try to create a cookie manually (on the remote machine), I get an error:

# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":0.0".
# echo $DISPLAY
localhost:11.0
# /usr/bin/xauth -f /tmp/ssh-ONrDZb6334/xauthfile generate :11.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/ssh-ONrDZb6334/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":11.0".

Do you know why is is failing to create a cookie?

I think that is precisely why the remote host needs ACL for local machine, therefore my 1st suggestion is probably correct.
There is another potential problem. If you login to X through xdm/kdm/gdm you probably have -nolisten tcp enabled (by default). Test like this

Code: Select all

ps wax | grep X

If you see -nolisten tcp, then change that in the *dm config files eg. /usr/kde/3.5/share/config/kdm/kdmrc, /etc/X11/gdm/custom.conf.

You shouldn't need to touch the [xkg]dm settings to make X11 forwarding work, the two are completely separate. However, is X11 forwarding enabled in the server config file? On the remote machine:

Code: Select all

grep X11Forwarding /etc/ssh/sshd_config

[at]

xhost authentciation is disabled (local machine):

# xhost +
# xhost
access control disabled, clients can connect from any host

There is no --nolisten TCP option (local machine):

# ps wax | grep X
4117 tty7 SLs+ 1:14 /usr/bin/X :0 vt7 -auth /etc/X11/xdm/authdir/authfiles/A:0-BZmf5F
6317 pts/0 R+ 0:00 grep --colour=auto X

X11Forwarding is enabled (remote machine):

# grep X11Forwarding /etc/ssh/sshd_config
X11Forwarding yes

And there is space on the remote machine hard drive to write a cookie.

Any other ideas?

Is there a way to turn logging somewhere to see why X refuses to create a cookie?

[notHerbert]

Try this:
Log into the remote machine, with "ssh -X".

Run "xauth list" and "echo $DISPLAY".

Get the magic cookie for your DISPLAY, and run on the remote host:

xauth add localhost:N MIT-MAGIC-COOKIE ...
... replacing N with an arbitrary display number for the local host's
display, and the ... with the cookie listed previously.

Then you should be able to run remote X apps locally.

[at]

The thing is that when I run "xauth list" on the remote computer, I get no cookies at all.

[notHerbert]

Can you make one up on the remote host?

Code: Select all

remote $ mcookie
remote $ xauth add hostname/unix:0 MIT-MAGIC-COOKIE-1 <output of mcookie>

Strange that there are none, are you logging into the user who owns the X session on the remote host ?

[deno]

Do oyu have 'ForwardX11 yes' in ssh_config on client machine?

[at]

'ForwardX11 yes' was not set on the client, I set it now, but it made no difference.

I tried

remote $ mcookie
remote $ xauth add hostname/unix:0 MIT-MAGIC-COOKIE-1 <output of mcookie>

but still to no avail.

Then I tried:

local $ ps wax | grep /usr/bin/X
4200 tty7 SLs+ 6:20 /usr/bin/X :0 vt7 -auth /etc/X11/xdm/authdir/authfiles/A:0-jHoqT2
local $ xauth -v -f /etc/X11/xdm/authdir/authfiles/A:0-jHoqT2 list
Using authority file /etc/X11/xdm/authdir/authfiles/A:0-jHoqT2
#ffff##: XDM-AUTHORIZATION-1 <cookie 1>
#ffff##: MIT-MAGIC-COOKIE-1 <cookie 2>

Then

remote $ echo $DISPLAY
localhost:10.0
remote $ xauth add localhost:10 XDM-AUTHORIZATION-1 <cookie 1>
remote $ xauth add localhost:10 MIT-MAGIC-COOKIE-1 <cookie 2>
remote $ xauth list
localhost/unix:10 XDM-AUTHORIZATION-1 <cookie 1>
localhost/unix:10 MIT-MAGIC-COOKIE-1 <cookie 2>
remote $ xclock
debug1: client_input_channel_open: ctype x11 rchan 2 win 87380 max 16384
debug1: client_request_x11: request from 127.0.0.1 41449
debug1: channel 1: new [x11]
debug1: confirm x11
X11 connection rejected because of wrong authentication.
debug1: channel 1: free: x11, nchannels 2
Error: Can't open display: localhost:10.0

So it still does not work with the same error.

All problems start when SSH session gets established and the following command gets executed by sshd:

remote: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-vYnbd21685/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200

That command fails:

remote $ /usr/bin/xauth -f /tmp/xauthfile generate :10.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
/usr/bin/xauth: creating new authority file /tmp/xauthfile
/usr/bin/xauth: (argv):1: unable to open display ":10.0".

(The same with display 0.0.)

So I wonder how X is supposed to authenticate ssh daemon from the remote machine when it is asking to generate a new cookie at the beginning of an SSH session?

I don't think I understood the question if the user owns the X session:
There is no X running on the remote machine. I ssh as a regular user and am try to execute "xclock".

[notHerbert]

When I run ssh -Y -vvv -l user host
I get this

.....
[/code](lots of ssh authentication stuff)
.....
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
.....
.....
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
...
Last login: Sun Sep 7 22:17:14 2008 from my.home.tux

~ me $ xclock
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 38886
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: rcvd adjust 40220
debug2: channel 1: rcvd adjust 49152
....
....
debug2: channel 1: rcvd adjust 49152
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: channel 1: will not send data after close
debug3: channel 1: will not send data after close
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
#1 x11 (t4 r3 i3/0 o3/0 fd 7/7 cfd -1)
debug3: channel 1: close_fds r 7 w 7 e -1 c -1

and xclock - or any other X app starts - without X running on the remote host, but it has a cookie.

Code: Select all

remote $ xauth list
remote/unix:10  MIT-MAGIC-COOKIE-1  <cookie>

The only other idea, did you setup passwordless ssh authentication? Could that make a difference?