On Mon, Jun 30, 2003 at 09:51:47AM -0500, Terry Todd wrote:
> On Mon, Jun 30, 2003 at 07:00:23AM +0200, Roman Neuhauser wrote:
> > # [EMAIL PROTECTED] / 2003-06-29 08:07:45 -0500:
> > > How do you get remote X to work with 5.1-RELEASE?
> > >
> > > Here is an attempt with some fields blanked out.
> > >
> > > $ xhost +
> > > access control disabled, clients can connect from any host
> > > $ telnet __
> > > Trying ___.___.__.___...
> > >
> > >
> > > [EMAIL PROTECTED]> xterm
> > > _X11TransSocketINETConnect: Can't connect: errno = 61
> > > _X11TransSocketINETConnect: Can't connect: errno = 61
> > > _X11TransSocketINETConnect: Can't connect: errno = 61
> > > _X11TransSocketINETConnect: Can't connect: errno = 61
> > > _X11TransSocketINETConnect: Can't connect: errno = 61
> > > _X11TransSocketINETConnect: Can't connect: errno = 61
> > > xterm Xt error: Can't open display: __.__.___:0.0
> > > [EMAIL PROTECTED]>
> > >
> > > The errno man page says errno 61 is connection refused. There is no
> > > firewall or anything on the laptop running 5.1-RELEASE on a local subnet.
> > > It is a fairly generic install except I had to recompile with OLDCARD.
> >
> > is the X server actually listening to remote connections? see
> > startx(1).
> >
>
> Yes, this is the answer. startx must now be run with the -listen_tcp option
> in order for remote X to work.
That's not entirely true. There's a reason why startx was modified to
prevent the X server listening on the network --- using a remote
session via the clear text X protocol is about as bad as using telnet
or rlogin or rsh: anyone can snoop on what you are doing and pick up
any passwords etc. you happen to type in.
Unless you're running solely over networks where there is no access by
untrusted parties, you should be using encryption to protect your
remote access. Generally that translates to "use ssh" -- and ssh(1)
can protect your X sessions in exactly the same way that it will
protect a tty based login session. It just needs a little
configuration first.
On your workstation (ie. with the screen in front of you), you need to
tell the ssh client to attempt to tunnel X sessions with the remote
machines you log into. Either edit /etc/ssh/ssh_config to change the
defaults system wide, or edit ~/.ssh/config to make the changes on a
per-user basis. You can select the systems you want to tunnel X stuff
from by name, eg. add:
Host foo bar *.example.com
ForwardX11 yes
(There's other options you can use here: see ssh_config(5) for details)
Note that the name match is against what you type on the command line,
not against the fully qualified name of the host.
On the X server, make sure that /etc/ssh/sshd_config does not contain
'X11Forwarding no'. The default on FreeBSD and other systems that use
OpenSSH (which is shown commented out in the sshd_config file) is to
permit X11Forwarding, so likely you won't need to change anything.
Now, to test, open a ssh session on a remote machine using the '-v'
verbose option:
% ssh -v hostname
Amongst the output you should see:
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: x11-req
and you'll find that the DISPLAY variable has been automatically set
in your environment on the remote system to something like:
% echo $DISPLAY
localhost:10.0
Now when you start up an X program on the remote, it should display on
your desktop, and all without having your X server listen on the
network at all.
Cheers,
Matthew
--
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
pgp0.pgp
Description: PGP signature
