Remote X operation

This page describes the use and pitfalls of xauth in Breezy.

xauth is a mechanism for enforcing access controls on X servers (displays). When an X server is started, it is given a randomly-generated "cookie". This cookie is written to a file owned and readable by the user whose session the X server is running. No other users can read that file. When an X client (application) is started, it attempts to read and use the cookie to authenticate itself with the server. If this "xauth" authentication fails, the application is not allowed to connect to the server and show windows on the X display.

The command

$ xauth list

will show the cookies available to the current session:

selene/unix:0  MIT-MAGIC-COOKIE-1  c2438e7c2858f142e0b81d6b4fe3867b
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  c2438e7c2858f142e0b81d6b4fe3867b

Traditionally, the location for each users' cookies has been ~/.Xauthority: the X server writes its cookies to that file as it starts up, and xauth (and other X clients) look in that file for authentication cookies.

Now, if you are sshed into an X server from somewhere else, and want to open an X client application on that display, you need to have appropriate xauth cookies available. This is where the problem becomes evident. Breezy's X server doesn't use ~/.Xauthority as its location for cookies. Instead, it puts them in /tmp/.<random-sequence-of-letters>, and then sets the $XAUTHORITY environment variable to tell xauth where to look for it. This environment variable is only visible to applications started from within the local X environment, so only the local user who currently "owns" the X display can know for certain where the right file is, and they can only do so from the X display.

If the owner of the X display wants to ssh into the X server from outside and run an X application on the display, then they must guess which file in /tmp contains their X cookies. This should be fairly easy for a single-display machine, because it will probably be the only dot-file in /tmp which is owned by them, and only readable by them:

hrm@selene:~ $ ls -al /tmp
total 101
-rw-------   1 hrm  hrm   117 2005-10-23 11:42 .gdmjnekKh

In the ssh session, setting $XAUTHORITY to point to that file will allow X client apps to connect to and use the X server.

An alternative solution is to place the following somewhere where it will be run on starting an X session (~/.xsession? I'm not a Gnome user -- I don't know if that'll work for Gnome):

rm ${HOME}/.Xauthority
ln -s $XAUTHORITY ${HOME}/.Xauthority

This will automatically link the newly-generated randomly-named Xauthority cookies file to ~/.Xauthority, where it can be found by xauth.

SSH X forwarding

You should really use SSH X forwarding whenever possible.

ssh -X user@host

If some older programs don't work, use

ssh -Y user@host


RemoteXHowTo (last edited 2008-08-06 16:32:10 by localhost)