X authentication over SSH, with Screen

Here's a problem: depending on how I login to my other Linux system (Spatula), two different X authentication methods are used. There's the usual ~/.Xauthority file, and there's a dynamically-allocated database thing - probably something GNOMEish. On Spatula, I logged-into GNOME via gdm, opened an X terminal and started GNU Screen. Little did I know that it was going to cause me problems later..

29-Jan-12: Here's an easier way to do this:

  1. Login with 'ssh -X' or 'ssh -Y'.
  2. Do 'xauth info' and note the 'Authority file' location.
  3. Attach to Screen ('screen -x' or 'screen -r').
  4. xauth merge [authority-file-location].

When I login to Spatula with X-forwarding on ssh - e.g. 'ssh -X spatula' or similar - then the forwarded display works okay outside Screen. As soon as I connect to the Screen session, I find that it's using a different X authority database. To use the localhost:10.0 screen, I have to add the X authentication cookie to the Screen database. Here's how I did it (my comments are shown in [square brackets]):

---------------------------------------------------------------------------
[outside Screen]

[Here, I get information about the current Xauth cookies.]

lex@spatula:~$ xauth
Using authority file /media/usb_disk/Spatula/home/lex/.Xauthority
xauth> list
[fe80::5049:49ff:xxxx:xxxx]:0  MIT-MAGIC-COOKIE-1  2df2f3b45222c467fe2161868b0897b0
spatula.brooknet:1  MIT-MAGIC-COOKIE-1  6cd27dc23882ed543cb9b6a4962c859a
spatula/unix:1  MIT-MAGIC-COOKIE-1  6cd27dc23882ed543cb9b6a4962c859a
spatula/unix:11  MIT-MAGIC-COOKIE-1  944db99bbb7d9d4fbd20ef21d499af41
spatula/unix:10  MIT-MAGIC-COOKIE-1  2e182bb7bef966b9b004cad558f9bdf4

[I am guessing that spatula/unix:10 is the forwarded connection]

xauth> quit
lex@spatula:~$ screen -x

[inside Screen]

[I 'tell' Xauth to use the standard .Xauthority file, which was in use
outside Screen.  Otherwise, it would have read the cookies from the GNOME
database, which is not what I want.]

lex@spatula:~$ xauth -f .Xauthority
Using authority file .Xauthority
xauth> list

[These are the keys in the .Xauthority file]

[fe80::5049:49ff:xxxx:xxxx]:0  MIT-MAGIC-COOKIE-1  2df2f3b45222c467fe2161868b0897b0
spatula.brooknet:1  MIT-MAGIC-COOKIE-1  6cd27dc23882ed543cb9b6a4962c859a
spatula/unix:1  MIT-MAGIC-COOKIE-1  6cd27dc23882ed543cb9b6a4962c859a
spatula/unix:11  MIT-MAGIC-COOKIE-1  944db99bbb7d9d4fbd20ef21d499af41
spatula/unix:10  MIT-MAGIC-COOKIE-1  2e182bb7bef966b9b004cad558f9bdf4

[Adding the cookie for the forwarded connection to the GNOME database]

xauth> extract /var/run/gdm/auth-for-lex-oVE9Jd/database spatula/unix:10
1 entries written to "/var/run/gdm/auth-for-lex-oVE9Jd/database"
xauth> quit

[Test it, by running xdpyinfo]

lex@spatula:~$ xdpyinfo
name of display:    localhost:10.0
version number:    11.0
vendor string:    The X.Org Foundation
..

[Sorted.  If I run Xauth with the GNOME database, it lists the new key.]

lex@spatula:~$ xauth
Using authority file /var/run/gdm/auth-for-lex-oVE9Jd/database
xauth> list
spatula/unix:10  MIT-MAGIC-COOKIE-1  2e182bb7bef966b9b004cad558f9bdf4
xauth> quit

[A problem: it's overwritten the old keys, so my local display probably doesn't work now.  No, it's okay - it still works.]
If all this seems quite simple, then remember that I usually run screaming from anything to do with X authentication. I'm sure it's straightforward, but I remember the days when the X Windowing System was a bit brittle, and to fool with it would cause it to come crashing down. These days, it's very stable indeed (touch wood). When I speak of those 'olden days', I mean running X apps over a 57600bps PPP connection with an Amiga 1200 on one end (usually running an early Debian, or NetBSD) and a PC on the other (running Red Hat Linux 5.0, or even 4.2!).
Back to the projects page
Return to the site index page