[lug] Newbie X-window questions

[Tkil]

>>>>> "Warren" == Warren Sanders <sanders at MontanaLinux.Org> writes:

Warren> If you have a faster net access between the two then you can
Warren> use a better encryption method with ssh (BTW ssh is not
Warren> telnet).  For slower service, use a lower encryption method.

Are you thinking "compression" instead of "encryption"?  ssh offers
both, and they're largely orthogonal.  

Encryption speed is a function of your CPU speed; I would guess that
even a modest modern computer (e.g. Pentium 100) can saturate anything
up to a T1 with any of the encryption types supported by ssh.  I
personally prefer blowfish, which is probably the most cpu-efficient
of the ciphers supported by version 1 of the protocol.

Compression lets you select a tradeoff between latency and bandwidth,
to some extent.  Higher compression requires more CPU (and more
memory, if that's an issue), but the bigger problem is typically that
it introduces higher latency in the communication path.  So, higher
compression is better for "batch" transfers, while lower compression
levels might be more useful for typical "interactive" sessions.

As an aside, note that some people have seen an improvement over
standard analog modems by turning *off* hardware compression in the
modem (v.42?) and just using the host-based ppp compression methods...

The original question has two parts:

>>>>> "Glenn" = Glenn Murray <gmurray at Mines.EDU> writes:

Glenn> If I have two Linux boxes, say "remote" and "local", then how
Glenn> do I open a window from remote on local?

In X parlance, "local" is running the X Server, while "remote" will be
running one or more X Clients, displaying on the X Server.  There is
the issue of which clients the server should allow to connect, since
there are serious security implications to allowing one to connect.
(Consider that it's very easy to write an X client that doesn't
display anything to the screen, but just collects all keystrokes --
say, like passwords!).  

The old way of handling this was called "host-based authentication",
where you allow all connections from a given host.  This has obvious
problems, but if you're behind a firewall, it might be enough.  'man
xhost' for more information on this.

The better way of doing this is to use cookie-based authentication,
using data normally stored in ~/.Xauthority and managed by the 'xauth'
program; take a look at its man page.  For straight TCP connections
using xauth, you would do:

1. Open an xterm locally.  type in "xauth list".  This should display
   a list that looks like:

      local$ xauth list
      local.foo.com/unix:0  MIT-MAGIC-COOKIE-1 759af84284cb577597b97cebfb71fb97
      local.foo.com:0  MIT-MAGIC-COOKIE-1  759af84284cb577597b97cebfb71fb97

2. Telnet to remote.  you want to add the tcp cookie (the second one
   above, without the "/unix" suffix) using xauth on remote.  I
   usually type in the first two words "xauth add " and then
   cut-and-paste the cookie from the xterm running on "local".  The
   command line ends up looking like:

      remote$ xauth add local.foo.com:0  MIT-MAGIC-COOKIE-1  759af84284cb577597b97cebfb71fb97

3. You want to tell all the programs on "remote" where to display.
   This is done with the DISPLAY environment variable.  For bash and
   ksh, you can do:

      remote$ export DISPLAY=local.foo.com:0

   Pure sh requires two stages:

      remote$ DISPLAY=local.foo.com:0
      remote$ export DISPLAY

   While csh uses "setenv":

      remote% setenv DISPLAY local.foo.com:0

Now you can run any X client on "remote" and it will display on
"local".  But...

Glenn> Is this secure?  

No.  The X protocol is not encrypted, and can be read out in clear
text if someone has access to the raw packets.

Glenn> I mean, if I have ssh telnet connectivity between the boxes,
Glenn> can I open X-windows via ssh?  

(Noting previous objection that "ssh" hasn't much to do with
"telnet".)

Yes, ssh has the capability to automatically set up everything we did
in stages 1-3 above.  You need to make sure that the client ssh (on
"local" in this case) is configured to request X forwarding, and that
the remote sshd (on "remote") are configured to allow it.  After that,
if you have DISPLAY set on "local" when you ssh over to "remote", it
should atomatically set up DISPLAY in your remote shell and you should
be able to run xterms (or any X client) easily.

Glenn> How much better is this?

Much better, since ssh will encrypt the X packets.  It's also much
more convenient, as it sets up your DISPLAY and .Xauthority for you.

Note that doing anything with the X protocol requires relatively high
bandwidth and low latency; remember that every mouse movement
generates an X event, just at a start!  I've done some X over dialup
56k lines, and it's not too much fun, but it's doable for text-based
things like xterms.  Something like Netscape, on the other hand, is
best done over ethernet speeds...

There are some X-aware protocol compressors, that do a creditable job
of improving this situation (e.g. they elide mouse events if they're
not significant or up to a certain threshold, etc).  The two I know of
are "LBX" ("Low-Bandwidth X") and "dxpc" (the "Differential X Protocol
Compressor").  Keith Packard has done an analysis on LBX, and found
that general-purpose compression (such as that offered by ssh) is
probably good enough:

   http://www.xfree86.org/~keithp/talks/lbxpost/index.html

Finally, there are other protocols besides X to consider, notably VNC:

   http://www.uk.research.att.com/vnc/

I'm not sure what the security implications are for VNC, but it should
be capable of tunnelling over ssh, which would give it all the
compression and encryption abilities that X has.

Hope this helps.
t.