[H-GEN] Secure and low bandwidth X through wireless broadband.

[Tony Nugent]

[ ... munch ... munch ... ]

> The solution here is just to tunnel everything via ssh.

An elegant, excellent, well-tested, and proven reliable solution.  For sure.  It
works.  Although there are all sorts of tricks to it.

> Now you can set up an ssh tunnel to port 3389 on a Windows 
> computer called "remotehost" with the following:
> ssh -L 3389:remotehost:3389 -N
> 
> The -N flag prevents a shell prompt from appearing, but you 
> can remove this if you want.
> 
> Once the tunnel is set up, then use a remote desktop client, 
> and connect it to your local machine.  The one built into 
> Windows doesn't let you connect to localhost (Doh!), but 
> rdesktop works very nicely (you're running X on your remote
> machine, right?)  :-)   The local  connection is sent across
> the tunnel to the Windows box, where it then gets connected
> to the remote desktop server locally.
> 
> I've used exactly this setup in the past (I had Windows installed on  
> VMWare on a Debian box), and I've found it to be quite responsive.   
> If you don't open up any other ports, then your security is 
> based on how much you trust ssh.
> 
> Regards,
> Paul

Just my 2c worth...

Port 22 sshd-scans are a big nusiance, I get hit with them up to a dozen or more
times a day.  If the server was responding to them (rather than being walled off
with wrapper settings in /etc/hosts.deny), then the buggers take note of the
open port and soon return with things like full-on dictionary username/password
attacks that can last for hours, days - and then return to do it all again.
Sometimes several attack can be going on at once.  A total pain (although a
relatively minor risk unless they do happen to fluke a valid user/pass
combination).

So that's good advice Paul gives there - if ssh is used for external access,
then make the server is listening on a non-standard high port (3389, or perhaps
22022, or whatever), then add the -P 3389 switch when connecting to it from the
client.

Also, the -C switch to ssh turns on data compression.  This can help
considerably (although I'm not so familiar with using cygwin on windows boxes).

In the past I've used both X and VNC across ssh tunnels over as little as 128bps
bandwidth with quite acceptable results, and better with more bandwidth.

If I recall correctly, X also has its own built-in compression
mechanism/protocol for remote access, and it can be used in conjunction with ssh
tunnels and ssh-X11 forwarding.  But it's been a while, and I'd have to read up
to recall the gory details.

I have no personal experience with doing windows remote desktop this way (using
ssh) - but it should work fine - although I suspect (with windows) that in some
situations it might require some tweaking (especially to make sure that the
routing and port handling is set up correctly on the windows boxes and firewall
etc).

It sounds like a fun project.  I didn't see the original message, as David seems
to use some weird mailer that wraps the main body of his message up in a
separate .txt attachment, and I've gone well past the point of bothering to open
them when they come like that.  Pity.

Cheers
Tony Nugent