Date: Tue, 18 Mar 2003 12:04:46 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-questions@FreeBSD.ORG Subject: Re: X11 remote connection problem Message-ID: <20030318120445.GB46378@happy-idiot-talk.infracaninophi> In-Reply-To: <Pine.LNX.4.53.0303180131340.10797@carlsberg.cs.ubc.ca> References: <Pine.LNX.4.53.0303180131340.10797@carlsberg.cs.ubc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 18, 2003 at 01:40:38AM -0800, Kan Cai wrote:
>=20
> Hey, all
>=20
> I know this question seems dumb, but it really screws me a lot.
> Following the handbook, I tried to make my remote X connection work, but
> with no luck. Here is the error message.
>=20
> #setenv DISPLAY my_machine:0.0
> #>gvim
> Xlib: connection to "my_machine:0.0" refused by server
> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> E233: cannot open displayXlib: connection to "my_machine:0.0"
> refused by server
> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
>=20
>=20
> I guess it is because I am using KDM instead XDM, so that the handbook
> instruction doesn't work. I am wondering if someone could instruct me a
> good reference page. I am using FreeBSD 4.7, KDE 3.0.
No --- this is controlled at the X protocol level, somewhat below
kdm(8) or xdm(8). You're actually running into a mechanism designed
to secure your system, and seeing as someone with remote access to
your desktop can do nasty things such as intercepting all of your
keystrokes or mouse clicks, knowing how to permit remote access by X
clients to your desktop securely is quite important.
I'm going to describe three ways of permitting you to display windows
=66rom a remote X application on your desktop, pretty much in order of
preference, worst to best.
i) xhost(1)
xhost(1) was the original mechanism for controlling remote access
to an X server. It's a pretty basic mechanism that just lists
hosts which are allowed to pop up windows on your screen. It's
only suitable for use on a private network where you control all
access to all machines on the network.
Examples:
% xhost +local:
Permit all users on your local machine to display windows on
your desktop. You should set $DISPLAY to: ':0.0' so that X
traffic goes via the Unix domain socket in /tmp, rather than a
network socket.
% xhost +inet:remote-machine
Permit all users on remote-machine to display stuff on your
desktop. Set $DISPLAY to 'local-machine:0.0' for this.
ii) xauth(1)
This is the replacement for xhost(1), which permits access based
on the remote user having access to a cryptographic token found in
the ~/.Xauthority file. This offers much finer grained control
than xhost(1), and it also underlies the third method I'll talk
about later. Much of what xauth(1) does is automatic --- when you
log in on your desktop, all of the right tokens are created if
necessary or an existing token is read out of your .Xauthority
file. In order to permit another user, either on a remote machine
or a different UID on your local machine, you have to extract the
tokens for your display from the .Xauthority file:
% xauth nextract - $DISPLAY > xauth-tokens
Now copy the xauth-tokens file to the remote machine and add them
to the .Xauthority file there:
% xauth nmerge xauth-tokens
and you should now be able to pop up windows to your heart's
content.
iii) ssh X-tunnelling.
Both of the previous methods suffer from the major flaw that all
of the X traffic is sent across the network in the clear. That is
approximately as bad as using rsh(1) or rlogin(1) instead of
ssh(1) --- anything you do can be snooped on, anything you type
into an X application, like the passwords to some system resource,
can be intercepted.
The best method of avoiding this is to always use ssh(1) to login
or run remote programs and enable the built-in ssh facility to
transmit X protocol traffic through an encrypted tunnel.
On the desktop machine, which is the X server but the ssh client,
make sure that:
ForwardX11 yes
appears in either /etc/ssh/ssh_config or ~/.ssh/config (obviously
in a 'Host' section matching the remote machine name) -- see
ssh_config(5) for details.
On the remote machine, which is where the X client runs and that
you access the xxh server on, ensure that:
X11Forwarding yes
appears in /etc/ssh/sshd_config (see sshd_config(5) for details).
Actually, that's the default setting: so long as 'X11Forwarding
no' *doesn't* appear things should work. If you change the
sshd_config file, tell sshd to reread it using a HUP signal:
# killall -HUP sshd
Now, when you ssh(1) into the remote machine, you should find that
the $DISPLAY variable is automatically set to something like:
% echo $DISPLAY
localhost:10.0
Make sure your shell initialization files don't overwrite that
setting or things won't work. The hostname part of $DISPLAY will
always be 'localhost' --- what's happening is that sshd(8) is
listening on port 6000 + displaynum (6010 in my example),
pretending to be an X server. Any X traffic it receives is
encrypted and sent over the network to your desktop machine, where
it is decrypted and fed into the real X server.
ssh(1) uses xauth(1) to automatically set up the ~/.Xauthority
files as in (ii) so that the X server will allow access. =20
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030318120445.GB46378>