PuTTY wish x11-auth

summary: Authenticate with local X servers
class: wish: This is a request for an enhancement.
difficulty: taxing: Needs external things we don't have (standards, users etc)
priority: low: We aren't sure whether to fix this or not.
fixed-in: r8305 (0.61) (0.62)

X11 forwarding currently doesn't even attempt to authenticate with the local X server. In order for it to do so, PuTTY would have to know where to look for authentication data. It would be nice if this were to happen.

A simple approach might be for PuTTY just to pass on authentication data supplied by the X11 client if it has no better ideas. The X Protocol Manual suggests that servers should ignore any authentication they aren't expecting, so this shouldn't break anything that currently works, and it would allow the user to copy back PuTTY's cookie to their real X server.
Ref: <web-71356@meredevice.com>

SGT, 2003-01-14: A couple of days ago I built in the infrastructure for this, since X forwarding in the Unix port of Plink is virtually useless without it. The platform-independent X forwarding code now has the ability to talk either of MIT-MAGIC-COOKIE-1 or XDM-AUTHORIZATION-1 to the local X server, provided a platform-specific function tells it what authentication cookie to use. So it's still not actually supported on Windows (since the Windows version of this function does nothing), but the amount of work that would need to be done to support it is now minimal.

SGT, 2008-11-04: I've just found this piece of source code which contains a comment describing the format of the .Xauthority file. So as not to lose it, I'll reproduce the format here. The .Xauthority file is an end-to-end concatenation of records consisting of a 2-byte big-endian number followed by four strings. Each string consists of a 2-byte big-endian number giving the length, followed by that many bytes. The strings are, respectively: network address, display number, authorisation method (e.g. "MIT-MAGIC-COOKIE-1") and the authorisation data itself. The initial bare number specifies the address family, i.e. how to interpret the address string. Just to prove it works, the following hacky piece of Perl successfully untangles the first .Xauthority file I could lay my hands on:

perl -e 'while (1) { read STDIN,$fam,2 or last; $fam = unpack "n", $fam; @strings = (); for $i (0..3) { read STDIN, $len, 2; $len = unpack "n", $len; $str=""; read STDIN, $str, $len; if ($i==1 or $i==2 or ($i==0 and $fam==256)) { $str = "\"" . $str . "\"" } else { $str = join "", "<", (map{sprintf"%02x",$_}unpack"C*",$str), ">"; } push @strings, $str; } printf "%s\n", join " ", $fam, @strings }' < ~/.Xauthority

and the output of this also suggests that family code 0 means the address string is a binary-encoded IPv4 address, code 6 means a binary-encoded IPv6 address, and code 256 means the address string is a hostname and the access method is a Unix-domain socket on that host.

SGT, 2008-11-17: should now be done, at least for Windows X servers which provide X authority files in the standard format. There's a new config option on Windows which allows the user to point at the location of their X authority file, and PuTTY has the in-built ability to understand files in that format.

Audit trail for this wish.

If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2008-11-17 18:40:07 +0000)