The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. [This message has been CC'ed to the OpenSSH list in a plea to at least consider supporting more advanced usages of Xauth] Chris Green <sprout at dok.org> writes:> Its not configurable behavior. It always generates a new random file > in /tmp.Then they should probably change that so that the user can specify a file to use. I need several programs to cooperate so I need a fairly central repository of cookies. It doesn't help if everybody starts using their own files for that.> possible cookies, or some unamed solution. If gnuclient passes the > creditials back to XEmacs via a unix socket everything is happy. My > solution doesn't work if gnuclient is being launched and expecting to > connect to XEmacs over an unencrypted tcp socket between machines.The problem is that gnuclient possibly uses tcp sockets to connect to the local machine too. Figuring out reliably whether an address is local is something I would rather not get into.> > Does openssh at the very least copy the other cookies from the old > > authority file, so that gnuclients's own auth cookie will be found? > > I'm not sure I follow here. The other DISPLAY's Xauth stuff is in its > own indepedant file and I don't believe there is anyway for openssh to > find out what the user's main XAUTHORITY is. They've designed openssh > to be used in conjuntion with local displays that also keep local > cookies. I think the gnuclient / XEmacs communication is the only way > one display can find out about the other.The problem here is that gnuclient itself also uses Xauth cookies to authenticate remote links. (It works by looking up the cookie for server-address:99). Consider the following scenario (which I use all the time) Open ssh tunnel from machine H to a machine A on the other network. Use gnuclient on A to tell an XEmacs running on B to connect to the A:10 fake display. For that gnuclient first needs the B:99 cookie to connect to gnuserver however it cannot find it because the cookie is actually in ~/.Xauthority.. It is no use trying to pass the A:10 cookie in the gnuserv session when you cannot connect to gnuserv in the first place/ Jan
On Sun, Nov 28, 1999 at 07:16:29PM +0100, Jan Vroonhof wrote:> [This message has been CC'ed to the OpenSSH list in a plea to at least > consider supporting more advanced usages of Xauth]You also wrote:> I don't like a solution that forces involvement of editclient.sh. > gnuclient should work on its own. The reason I don't like openssh > mucking around with the xauthority stuff so much is that the cleanest > solution would be for gnuclient to pass the cookie from its > environment to XEmacs, however that could also be along a nonencrypted > connection which is worse than over the file system. > > Does openssh at the very least copy the other cookies from the old > authority file, so that gnuclients's own auth cookie will be found?openssh does not _muck_ around with the xauthority stuff. the openssh-server create a fake cookie and places this fake cookie in /tmp/XauthXXXX. if a x11-client is started on this machine the cookie is read from the file, the x11-request sent to the sshd, sshd forwards the request to the ssh-client, the ssh-client replaces the fake-cookie with the real cookie and sends the request to the x11-server. the game with the fake-cookie is played in order to make the cookie saved on the server short-lived. so it makes no sense copying the long-lived cookies to the ssh-sever. can you provide detailed information on 'how' gnuclient works? other than this, you can overwrite the behaviour with your own ~/.ssh/environment, see sshd(8). ?markus
> 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