X-Server refuses connection

[krose at theory.lcs.mit.edu (Kyle R. Rose)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Shame on me!  I asked this question before, and got the
> answer, but now the problem has reappeared and I'm
> damned if I can find the original solution.
> 
> I'm trying to log onto an X-Windows application, but it
> fails after I export the display and start the
> application, saying the X-Server refused the
> connection.  Please tell me how to change Xfree86 so
> that it accepts any connection request.

You should probably look at the xhost(1) man page for an easy
solution.  If you're looking for the secure solution, you should man
xauth(1).

Basically, xhost allows you to give X server access to anyone on a
particular machine; this can lead to some really funny pranks like
10,000 xeyes appearing on your display.  It can also lead to anyone on 
that machine being able to dump a copy of your display, which might
contain private information.  Generally, xhosting a machine you don't
have complete control over is a bad idea, and attacks on name servers
can negate even the little security it provides.

Enough of the security sermon.  If you are running the particular
program on host foo.bar, you would say

xhost +foo.bar

and clients from foo.bar would be allowed to connect to your X server.

The better solution is to use xauth to give access only to _your_
clients running on a particular machine.  If you pop open an xterm on
your local machine and type "xauth list," you'll see something like

twilight-symphony/unix:0  MIT-MAGIC-COOKIE-1  15fc458a5d0249837b987c987d9827f959
twilight-symphony.glassmoon:0  MIT-MAGIC-COOKIE-1  15fc458a5d0249837b987c987d9827f959

(Yes, those cookies are munged for all you would-be pranksters out
there.)  The cookies (the long hex numbers in the above lines) are
just long (128-bit) random numbers which are required to connect to
your X server; since it's very difficult to guess a random 128-bit
number (as there are about 3.4x10^38 of them), this is considered good
security.

So, how to get the cookie to the machine you're running the client
from?  Well, you can extract the remote cookie (the non-unix socket
one) to stdout using the "extract" option in xauth, like so:

xauth extract - twilight-symphony.glassmoon:0

and then import it from stdin on the other end using the merge command:

xauth merge -

Unfortunately, you need some kind of secure login to ensure that the
cookie doesn't travel over the network in plaintext: I use ssh.  With
ssh, the entire command would become something like

xauth extract - twilight-symphony.glassmoon:0 
 | ssh -l krose foo.bar 'xauth merge -'

This would transfer the cookie for the current X session to the remote
machine; now you can run clients from that machine until you restart
the X session.

(The preceeding example was somewhat specious, because ssh does its
own X11 forwarding that doesn't require you to wank around with xauth:
it does all the magic on its own.  That may, in fact, be your best
solution.)

Kyle


- -- 
Kyle R. Rose                    MIT LCS NE43-309, Cambridge, MA
11 Winslow Avenue Apt. 2        617-253-5883
Somerville, MA 02144            krose at theory.lcs.mit.edu
617-628-0271                    http://web.mit.edu/krr/www/

They can try to bind our arms,
But they cannot chain our minds or hearts...
                        - Stratovarius
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.10 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE30ovh66jzSko6g9wRAjOdAJ4sXbPYT8flPIf6tOvPT1gHrFmqiwCg894l
rW72JDqjrA8wHPlMSslzEXg=
=4azF
-----END PGP SIGNATURE-----
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).