[lug] Newbie X-window questions

Wed May 9 10:18:04 MDT 2001

On 9 May 2001, Tkil wrote:

> Date: 09 May 2001 11:10:15 -0600
> From: Tkil <tkil at scrye.com>
> Reply-To: lug at lug.boulder.co.us
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] Newbie X-window questions
>
> >>>>> "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.
>

Yes I goofed, I meant "compression" rather than "encryption", my
apologias.

> 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.
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>

-- 
Warren Sanders
http://MontanaLinux.Org