Road Warrior Setup: SSH

As I said in my previous post, I wanted to create a secure way to connect to my home network when on the road.  One of the things to realize is that there is no one right way to do this, as individual needs vary and depending on where you are connecting from, the abilities of the network may vary.

One great way to connect to your home network in a pseudo-VPN way is via SSH (or Secure Shell).  Strictly speaking, creating an SSH session with a server is not a VPN, however, we can leverage the protocol to simulate much of what we need.  SSH was developed in the mid to late 90's as a way to remotely execute administrative tasks, where other protocols (like telnet) simply do not provide enough security.

SSH is not that frequently used Windows boxes, but it is common (and built in) on Linux machines.  Since many routers are running Linux-based firmware (or capable of running such) SSH servers or daemons are often built in.  However, it also supports tunneling, so we can use this as a sort-of lightweight VPN solution.  While it may not provide the richness of a full VPN, it is likely the easiest method to get in place, the connection can be terminated at the router (meaning, no server to set up behind the router), and SSH uses only TCP port 22 (by default), making it very compatible over most networks and NAT.

To get started, you'll need an SSH endpoint -- basically, firmware on your router that includes an SSH daemon.  In this case, I'll look at doing this in Tomato.  Next, we need an SSH client -- one of the best is PuTTY.  Not only is it a client app, but also contains some helper tools we can use.

The first thing to do is launch the PuTTY SSH Key Generator, and generate a new public/private key pair.   Click generate, modify the key comment (if desired), enter a passphrase.  Copy the public key (in the top window) into the clipboard.  It should look something like this:

Save the private key some place secure -- this will need to be on any machine you use to connect to the SSH daemon.  BUT, the key itself should never be transmitted over insecure means -- meaning, don't e-mail the key!  If you need to, you can create alternate keys for different users.

Logging into the firmware, we'll set up the SSH options by enabling the SSH daemon, setting the port (default is 22), and pasting the keys into the authorized keys section.  We'll also disable password login.  While this screen is specific to Tomato, any other firmware that has an SSH daemon built in should have equivalent functionality:

Now in the PuTTY client, we'll set up the connection settings (note you can save your settings to be recalled later):

And then we'll go to the Connection -> SSH -> Auth section and tell PuTTY where our private key is:

Clicking Open on the Session page should now open a terminal window to our server, and if all goes well, we'll log in (as root) and be prompted for the passphrase for our key.   (The passphrase, just as a point of interest, is a security measure strictly client side to help prevent the key from being easily decrypted.   For more information on how this works, check out the PuTTY site.)

Now here's where we can have a little fun using the tunneling capability.  On the Connection -> SSH -> Tunnels screen, we can define a few tunnels to support some applications.  Here, I want to set up two tunnels.  The first is to define a tunnel from local port 3392 (this was a subjective choice, however, it has to be an available port on the local machine) and map it to a machine on my home network, in this case, to port 3389 (remote desktop).  To set this up for the first time, you'd enter Source port 3392, Destination, and click the Local radio button.  We'll talk about the D10511 highlighted below in a minute:

What this does is tunnel our local port 3392 over SSH to the remote network.  So, by opening a remote desktop connection, I'd do it like so:

Now, it's true that the remote desktop protocol is by default encrypted, but most folks don't like leaving their machines exposed to the internet unless they have to.   We could easily map multiple ports to different end points, so we could connect to a number of machines on the remote network if needed.

Now, if we want to, we can also use SSH as a SOCKS proxy -- essentially allowing, say, a web browser to tunnel a connection to the remote network and browse as if we we were on that network.  Very handy if you're worried about an hotspot watching your traffic.  To set this up, we'll enter another tunnel in the PuTTY Tunnels config -- in this case, I arbitrarily picked port 10511, left the destination blank, and selected the dynamic radio button.  As the name implies, this allows the endpoint and port to be dynamic, as is needed (naturally) for browsing on the web.

Then, to use this, all we need to do is configure a web browser (in this case, I'll configure Firefox) to use the local port we chose (10511) since that's our tunnel:

It looks counter-intuitive to leave the "No proxy for localhost..." entries, but because we're using localhost as a proxy anyway, it doesn't matter if we leave them in.

So, the pros of this setup is that it's easy to set up (if you can remote admin via the web into your router, you could even set this up remotely!), and it's very NAT friendly.  Should work over just about any network, relying only on TCP and the port is configurable. 

The biggest drawback is that this isn't a true VPN.  You have to explicitly set up the applications you want to forward, and if those applications use multiple ports, it can get very messy. 

Next up, I'll look at PPTP and OpenVPN.

Comments (2) -

6/16/2008 7:07:46 PM #

this is great. thanks for all the detailed info.

7/7/2008 8:56:26 PM #

Thanks for the tutorial - perfect!

Comments are closed

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List