gnuclient X11 & openssh

[Jan Vroonhof]

> openssh does not _muck_ around with the xauthority stuff.
> the openssh-server create a fake cookie and places this fake cookie
> in /tmp/XauthXXXX.

And it sets the XAUTHORITY  variable to point there. The cookies file
is a database where there are multiple cookies stored. The normal ssh
adds its cookie to this database. What openssh seems to do is to
create a new database in /tmp/XauthXXXX and then point all the
programs there through the  XAUTHORITY environment variable.

This works OK in normal situations where you only connect to one
display and thus need the one cookie, but it is wrong in case one
connects to multiple diplays (and for this purpose the gnuserv program
is just another display)

> the cookie saved on the server short-lived. so it makes no sense copying
> the long-lived cookies to the ssh-sever.

No I meant other cookies that could already exist on the server side.

> can you provide detailed information on 'how' gnuclient works?

There are two setups.

A: Unix domain sockets
1. XEmacs is started with gnuserver and normally with a frame open on a
display , say A:0
2. gnuclient is started on the same machine. It reads its value of
   display, say A:10 and passes this down the socket.
3. XEmacs looks up the cookie for A:0 and opens the display

This fails in step 3 because OpenSSH has used its own cookie file and
thus the value of XAUTHORITY is different in 2. from that when XEmacs
was startup in 1.

B: TCP/IP sockets
1. XEmacs is started with gnuserver and normally with a frame open on a
display , say A:0. If this is on host H then gnuserv looks up the
cookie for H:99 and starts listening on a specific port.
2. gnuclient is started (possibly on another machine). It looks up the
value of H:99 and opens a socket to gnuserv at H and sends the cookie for
H:99 down the sockets.
3. Gnuserv at H compares the cookie it got from the client with its own
value and if they match allows the connection.
4. Gnuclient reads its value of
   display, say B:10 and passes this down the socket.
5. XEmacs looks up the cookie for B:10 and opens the display

This fails at two points.
i. The cookie for H:99 will not be int /tmp/authXXXX if sshd didn't
   copy it and thus gnuserv will refuse the connection.
ii. As before XEmacs will not be able to find the cookie for the B:10
display because it is not in the cookie file it sees.

Basically the fundamental problem is that openssh's default using the
Xauth file as a file with a single cookie instead of a database. There
are also other cases (not involving gnuclient) where this causes
problems.
Openssh is braking a fundamental property the Xauth mechanism. The
cases where this causes problems might be rare and the cause (enhanced
security by default) may be good but should you a. be aware
that you are breaking it and b. it should be documented/

> other than this, you can overwrite the behaviour with your own
> ~/.ssh/environment, see sshd(8).

I looked at the manpage from www.openssh.org, but there
1. The specific behaviour of openssh isn't documented at all.
2. It isn't clear from the manpage that setting ~/.ssh/environment
   will work. If I set XAUTHORITY there, will sshd respect that?
3. From the manpage I get the impression that ~/.ssh/rc should be used
   instead.

Jan