[H-GEN] remote X

Ben Carlyle benc at foxboro.com.au
Mon Jan 3 23:14:21 EST 2000


[ Humbug *General* list - semi-serious discussions about Humbug and ]
[ Unix-related topics.  Please observe the list's charter.          ]

> I've telneted to local machine shivan from serra and would like
> to run X apps but get the following...

> [staeci at shivan staeci]$ xterm &
> [1] 1939
> [staeci at shivan staeci]$ Xlib: connection to "serra:0.0" refused by server
> Xlib: Client is not authorized to connect to Server
> xterm Xt error: Can't open display: serra:0.0


There are a couple of ways to do it.  The way everyone does it, and
the correct way :)

Method 1)  Open up all security restrictions for a particular machine.

While still logged on locally type
> xhost +
to give access to all machines everywhere to your display.
This is just about the worst thing you can possibly do to yourself,
and should always be accompanied by rules in the /etc/hosts.* files
to keep the baddies out.  Once your display is open to a malevolent
entity they can do everything from subtly interfere with your work
to running nuisance programs to killing your own programs to easily
capturing passwords and other info you hold dear to you.

> xhost +staeci

is a more gentle drop of your security restrictions.  It will only
allow promiscuious sharing of programs in your display space with
the specified host.  This is nicer, but may still be open to exploits
if you're online and your attacker has a DNS handy.

To reverse these commands type
> xhost -
and
> xhost -staeci
respectively.

Method 2)  Gritty token-based scheme.

This is the way things work on your own machine:  XDM starts the 
system and defines a cookie, which is just a random number that
will hopefully be hard to guess and which lasts throughout your
whole session.
To find out what your cookie is, try the following:
> xauth list
benc-pc:0  MIT-MAGIC-COOKIE-1  edcba987654321321431234123412311
andreww-pc:0  MIT-MAGIC-COOKIE-1      abcd1234567878123415146145132411
(numbers changed to protect the innocent :)

This shows that on my own host (benc-pc), I have access to a session
with session ID edcba987654321321431234123412311, and I have evilly
gained access to another users's session.  So long as the same XDM
session is running I can use the cookie specified to open windows on
that display regardless of the xauth state.  The cookie I hold is
literally the password until session ends.  It should be noted that
at this point I do not have access to andreww-pc:0, since my cookie
is long out of date.

So, you know how to find out what your cookie is.  Here's how to
place it in the other box:
> xauth add benc-pc:0  MIT-MAGIC-COOKIE-1  edcba987654321321431234123412311

Nice and easy.  It's just a cut and paste job.
The cookies themselves are usually kept in the file ~/.Xauthority
which is a binary file, so use "less" to peek at it.  This is
arguably a more secure way to setup permissions, as no amount of
DNS faking is able to fake that cookie.  The point of failure of
the authentication scheme moves to the transport of the actual
cookie between machines, which usually means that an attacker must
be on your local lan in order to take advantage.  If things do start
to go strange, logging in again will create a brand new cookie for
an attacker to guess, and as you can see from the number's length
that will usually take quite a number of attempts :)

This cookie-based scheme requires a cut-and-paste more than the
simple xauth +hostname, but may provide better security.  I use
it whenever I'm not feeling lazy.


Method 3)  ssh

Now that you know the correct way, here is the most secure and
simple of the lot.  Instead of using telnet, type the following:
> ssh staeci
ssh will automatically tunnel X connections back to your home
display, and provides a level of security which greatly surpasses
both of the previous methods.  Try it out, and tweak the settings
a little if you like.  It can also do cute additional things such
as on-the-fly gzip compression for slow connections.  The ssh
option will of course increase your performance hit, but for most
applications it is reasonable.


Benjamin.

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.



More information about the General mailing list