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 cvar@rambaldi.thruhere.net
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 cvar@rambaldi.thruhere.net 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
If you enjoyed this article, please consider sharing it!
Use
ps ax | grep ‘ssh[ ]‘
to identify the tunnel’s process and ‘kill’ it
instead of
ps aux | grep ssh
Sure, that’s more precise :)
Isn’t it true that if you establish this connection in a public location network, then anyone can piggyback your connection, i.e. port 80 forwarded to another machines’ port 22 will allow anyone in the same subnet to use the connection without verification?
Nope, with the kind of connection we show that’s not possible. But if the *remote* box you’re tunneling to is in an insecure LAN, then all sorts of bad stuff could happen.
What happens to your traffic if the SSH tunnel crashes or is just exited? Your traffic would follow the default gateway which is the router in front of you. Right? That doesn’t sound secure to me. Maybe you could have a virtual machine with an IP scheme and routing that only works with the other end of the tunnel. If the tunnel “died” then the VM wouldn’t have anywhere to send the traffic until it was re-established. I just thought of that so I could be wrong. I haven’t really thought it through.
You’re making an interesting point. If for some reason the tunnel collapses then the browser that’s been using it won’t be able to send or receive traffic until its proxy settings are re-configured.
Provided you know what you’re doing, SSH tunneling is an easy and efficient way to have privacy for the applications that actually use the tunnel. If you want to re-route all of your computers traffic through a secure, encrypted channel, well, then you should consider a solution like VPN tunneling. But that’s a subject for another post :)
Can we establish a ssh tunnel from our mobile phone?
Don’t know. Maybe there’s an app for Android devices and/or jailbroken iPhones but I’ve never checked :S
ConnectBot is one Android app that does ssh. I’m sure there are others. Don’t know about tunneling, though, I haven’t tried to.
yes, there is an app for ssh on android market and it’s very usefull.
I use ssh “-D” (dynamic proxy) from my linux laptop frequently to proxy my browser sessions outbound. Note that, at least for google chrome, you must also turn off “DNS prefetch” in preferences/under this hood otherwise all your DNS lookups will not proxied potentially spilling your browsing history to the local administrator.
Aha. Didn’t know that about Chrome. Thanks for the tip!
You may change some config in Firefox to avoir your DNS request to resolve locally. This leave less traces and you’ll have better privacy.
Goto About:config
and set “network.proxy.socks_remote_dns” to yes.
So you’ll use you home DNS instead of your actual place DNS.
The only DNS request that will be traceable will be you dynamic DNS home address.
Regards,
BT
That’s a very interesting and useful tip. Thanks!
Great article.
Can someone confirm that this method works in USA Starbucks?
Thanks
In firefox you can use “foxy proxy standard” and create a profile for the given ssh tunnel. The tricky part is when you have to connect from a windows machine using authentication…
If you have a good network and a gnu/linux box on a relatively secure network, it’s easy to route everything by:
ssh -X user_name@hostname_or_IPaddress
then start your browser. Firefox has an obnoxious script that prevents the remote machine from running the browser for you but Konqueror and others do not. This method may be slow, especially if you don’t have good flash and adblocking in place, but everything really comes from the remote machine.
I’m amazed by the relative complexity and futility of doing similar things with Windows. I sometimes use the gnu/linux way to make Windows RDP more secure if I have to access a machine at work and this incurs almost no additional speed penalty but exporting a whole desktop is big slowness and doing it with Windows’ half done encryption is a waste of time. Because somewhere between a quarter and most Windows computers are compromised by some kind of botnet, I would never type a real password into it or use it to connect to a secure computer. Efforts to protect against the dozen or so people at a coffee shop are kind of silly when Windows itself is so easy to compromise by rogue advertisements, viruses and other net nasties served by hundreds of millions of broken Windows machines all around the world.
Nice article, but how are you bypassing the local router? The traffic still has to use the local router to go out to the internet and could someone who hacked the router still not do packet sniffing (even through your data should be encrypted)?
Thanks
You’re right. You cannot bypass the local router but what you *can* do is use the encrypted channel for all your web browser’s network traffic. And in that case packet sniffing can’t reveal anything about your browser’s data stream. Now, if you want to send all of your computer’s traffic through an encrypted channel, then VPN tunneling is what you’re looking for. And as I mentioned at the end of the article, that’s a subject for another post (or two :D)
Worth noting: OSX and Linux (and probably everything else, too) have system-wide SOCKS proxy support. Enable this and all applications (Firefox, Thunderbird, Adium, Pidgin, etc) go through the SSH tunnel. Much easier than configuring every single application separately ;)
(applications need to be already configured to “use system’s proxy settings”)
Awfully simple to set up, great article.
I just installed the Proxy Switchy extension to Chrome, so i can easily switch from ‘work’ setting to a ‘private’ setting.
i have to ask….. would it work to “chain” together the ssh tunnel to TOR???….. that is “local-$$random browser” to “ssh-server” and on “ssh-server” have it setup to tunnel straight to TOR??
Although I’ve never tried something like that, I’m pretty sure you can. Let me try this with my home server and get back to you. Come to think of it, I might post a short article describing the whole setup. Thanks for the inspiration!
Adding a layer of tor proxy would hide your real ip address from the site you’re connecting with ssh. I would use tor to hide my ip from an insecure site. Since you’re ssh’ing to your home, i don’t think it is an “insecure” site ??? Why would one hide its ip from it’s home computer ???
Just my .02$,
BT
What you say is not what javabean has in mind. To my understanding the Tor proxy runs on your home server, so whenever you securely surf the web from your laptop through an SSH tunnel (to your box), you get strong anonymity as well.
that is correct subZraw, that was my point….. although i admit i might be tempted to run my laptop via tor while i am out and about, not all “wifi-hot-spots” will accept/appreciate one of the “laptops” connected to them running a tor relay-node and/or exit-node.
How about this scenario?
You come across a router hotspot secured only by WEP. You crack the WEP. Then you use VPN-tunneling to secure your traffic on the router. But lo, you see that the router is packet-sniffing. (Why would they use WEP if they know how to packet-sniff? Let’s say they’re temporarily allowing someone’s old OS X — which has trouble with WPA — to login, or something.) Plus, you’re the only user (other than the actual admin) within range of the router’s WiFi.
1) Despite your VPN tunnel, could the router’s tech-savvy owner at least detect that *someone* is using the router? They wouldn’t know it was you; but, they’d know it was someone?
2) Since they can survey the physical territory covered by the WiFi, they know it’s you, the only person (other than the actual admin) there. Or am I missing something?
Thanks!
You’re right, it’s easy for them to see how many clients are connected to the router. The only thing they need to do is navigate to the router’s web interface and check the ARP table, the connected clients list or something similar. And they will see your client too, despite your VPN tunneling.
Now, if they survey the physical territory they might see other people with their laptops, iPads, smart phones etc. And those people may be getting online by other means, e.g. using their 3G connections. So, even if there’s only one client (besides the admin) connected to the router, in general they won’t be able to tell it’s you.
gSTM is the graphical “Gnome SSH Tunnel Manager”. It is a great GUI and makes it easy for you to set up tunnel connections for the less technical to use.
Thank you for the useful information.
I live in Iran and I’m using this kind of tunneling to bypass the limitations and censorship caused by my ISP. Everything was Ok for the last year but recently my connection through the tunneling has been so slow. I think a new limitation rule is forced by my ISP which I don’t know what it is.
What kind of things can cause this problem?
Thanks in advance,
Hi there,
I’m glad you found this post useful. As for the slow speed issue, well, my guess is that your ISP must have gotten some kind of traffic shaping mechanism in place. You can try using a port other than the default (22) for your tunnels, but bear in mind that this trick might not work. Anyhow, if I were you I’d try a high port such as 2222 or something.
Thanks! Really helped!