Mindlessly surfing from an insecure location such as a coffee shop, a hotel room or even your workplace? Sure you are and we can understand the need -and oftentimes the urge- to be online. Hopefully, there’s an easy way to have all the security of the world and check your email and/or surf the web at the same time.
The idea here is that you establish a secure, encrypted SSH tunnel from your laptop to a remote box you own or at least have an account on. By doing this you essentially bypass the local router and surf through the remote machine. So, not only do you avoid attacks such as packet sniffing or SSL stripping, but you also go around any technical barriers (e.g. URL blacklisting) the admin of the local network you’re getting online from has in place.
Before we demonstrate exactly how you can accomplish that, we should clarify a few things about the remote computer. First off, its operating system should be either Linux, BSD or Mac OS. The box must be online and capable of accepting inbound network connections, that is to say connections from the Internet. What the latter usually implies is that the proper port forwarding or NAT rule is already setup in the router the computer connects to. More specifically, the remote computer runs an SSH server and accepts inbound connections to the appropriate port (the default is 22). Furthermore, the firewall it may have enabled should allow for connections to that port.
As for the client machine, i.e., the laptop or even the desktop computer you intent to establish a secure tunnel from, it may be running any operating system you like.
There’s one more thing. Sometimes it’s best for the client and server to be configured for passwordless SSH logins. Such an arrangement is not mandatory but it sure makes things easier. Check this post out if you want to know how to accomplish that.
SSH tunneling from Windows
We need an application for Windows, capable of establishing SSH connections. One of the best -and completely free- choices is our good friend PuTTY. For the remainder of this section we assume that you already have it and of course know how to use it.
So, open up PuTTY and choose the profile for your SSH server. For the sake of our demonstration, let’s assume that the fully qualified domain name of the remote box is rambaldi.thruhere.net (yes, we love DynDNS) and the profile we work with is named rambaldi.
In the PuTTY Configuration window make sure the profile you want is selected, then click on the Load button at the right side.
At the left of the window there’s the Category column. In it, navigate to Connection –> SSH –> Tunnels. Notice the Source port text box at the right side of the window. In it, type 1080. Underneath the text box, make sure the Dynamic and Auto radio buttons are selected, then click on the Add button.
Inside the text area above, you’ll see a new entry – in our example D1080. That’s good.
In the Category column of the PuTTY configuration window, click on the Session at the top, then on the Save button. You’ve just successfully modified the existing profile and saved the changes.
Click on the Open button at the bottom of the PuTTY configuration window to establish an SSH connection to the remote box. After successfully logging in, you’re almost done: Just configure your web browser of choice to use 127.0.0.1:1080 as a SOCKS proxy and from this moment on the browser will be communicating with the outside world through the secure, encrypted tunnel from your computer to the remote box. If for any reason you want to shut down the connection, just exit PuTTY the normal way.
Have any questions so far? Are you wondering why we used port 1080 or how exactly to configure your web browser? If so then you should know that all your answers will be answered by reading the following section ;)
SSH tunneling from Linux/BSD/Mac OS X
Fire up a terminal window and type something like the following:
ssh -p remoteport -D localport -f -C -q -N username@remotebox
Admittedly the "following" is vague enough, so let’s clarify things a bit.
remoteport: This is the port the remote SSH server uses for inbound requests. The default is 22 but in a home setup it could be any port higher than 1024. It all depends on the NAT rule in the router the remote box connects to.
localport: The -D parameter specifies local, application-level port forwarding. This works by allocating a socket to listen to localport on the localhost. Whenever a connection is made to this port, it is forwarded over the secure channel and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. (Note: This paragraph is a slightly modified version of the original found in the ssh man page.)
username: The user name of the account on the remote box we’re connecting to.
remotebox: The public IP or the fully qualified domain name of the remote box.
-f: Instructs ssh to go to the background, just before command execution.
-C: Enables data compression.
-q: Causes the suppression of most warning and diagnostic messages.
-N: Disallows the execution of any remote commands.
Let us now see an example of SSH tunneling:
mbblack:~ sub0$ ssh -p 19595 -D 1080 -f -C -q -N email@example.com
Immediately after executing the previous command we establish a secure SSH tunnel from the local machine to rambaldi.thruhere.net. The remote account we connect to is that of cvar’s. Because of the NAT rules in the router in front of rambaldi, instead of the default port (22) we connect to 19595. On the local side, we allocate a socket to listen to port 1080. All connections made to this port are re-routed through the secure, encrypted channel.
In order for our web browser to utilize the secure tunnel we ought to configure it for using 127.0.0.1:1080 as a SOCKS proxy. One convenient Firefox add-on for defining and using various kinds of proxies is FoxyProxy. In any case, even the manual proxy configuration is not a terribly complicated task – no matter what your browser of choice is.
When we no longer need the SSH tunnel it’s a good idea to explicitly close it. Here’s an example of how we do that from the command line:
mbblack:~ sub0$ ps aux | grep ssh sub0 2768 0.0 0.0 2435116 524 s000 S+ 6:09PM 0:00.00 grep ssh sub0 2763 0.0 0.0 2435168 260 ?? Ss 6:09PM 0:00.00 ssh -p 19595 -D 1080 -f -C -q -N firstname.lastname@example.org sub0 2762 0.0 0.1 2457636 2504 ?? S 6:09PM 0:00.04 /usr/bin/ssh-agent -l mbblack:~ sub0$ kill 2763
A word of warning
Establishing a secure SSH tunnel doesn’t mean that all of our computer’s network traffic travels through it. The only packets that are sent and received through the tunnel are those of the application that is configured to actually use the tunnel – in our case the web browser. Should we desire *all* of our computer’s network traffic re-routed through a secure channel we should consider tunneling through a VPN server. But that’s a subject for another post. Visit often – soon you’ll have a chance to read some detailed HOWTOs on VPNs too :D