Surfing a Secure Tunnel via SSH

I found this interesting article, over at macapper.com which I’ve quoted for your convenience! Please go check out the original article though!

“So there you are in your cubicle at work utilizing your employer’s expensive internet connection for everything except something that can actually justify your pay check. This is a good enough time to do some power ebaying, youtubing, or hell even some chatty chat with that sexy new bit on the side. It doesn’t get any better than this right? To actually get paid to surf the internet whilst firing off a reply to the occasional email, to keep up the guise of you actually being alert and attentive to the various happenings at work. Imagine if your poor sap of a boss actually knew what you were up to!

Guess what, chances are he does. Or is about to.

digg_url = \’http://digg.com/apple/Advanced_OS_X_Surf_a_Secure_Tunnel_via_SSH\’;

There’s always some little weasel of a sys-admin just waiting to inform “the man” of just how much time you, his star employee, is actually NOT spending justifying that paycheck. Just imagine when the schmuck presents ream after ream of printed logs of your questionable online antics. IRC, MSN Messenger, AOL Messenger, YouTube, pr0n, and the list goes on. You get the picture. Now before you fire up Monster.com on your soon to be former employer’s dime, there is thankfully an answer.

SSH Tunneling
The concept is simple. All your activities are sent through an encrypted SSH tunnel to some remote server which in turn does all the dirty work (so to speak). The beauty of course is that all that nuisance of a sys admin can ever see is a bunch of encrypted traffic.

Now here’s what you need:

• openSSH client. (thankfully OS X has this built in!)
• access to an openSSH server

For item 2 we are going to assume you have access to an offsite server somewhere that you can log in to via SSH. Perhaps you have a dedicated server at a hosting company? Maybe a Linux or FreeBSD box at home. You could even run an openSSH server on a Windows machine. Of course you could also use the Mac you have at home too! If you really don’t have access to a fast box to surf via, Google will likely lead to some free solutions. The only caveat to whatever box you use as a server is that it has to be configured to allow you to login via ssh. That’s it, that’s all.

Now in case you aren’t grasping this. The “client” is your computer at work. The “server” is the other machine we will tunnel to.

Getting Started
First you will need to create the tunnel. We need to know the name or IP address of the server you will be tunneling to, as well as your login name and password on that server. For this example we will assume your login name is william and the server name is www.myserver.com.

Now enter the following into your terminal window.

ssh -D 8080 -f -C -q -N william@www.myserver.com

You will then be prompted for your password, which you should enter. That’s it! Your ssh tunnel is in place!

A quick synopsis of what those switches mean is as follows:

-D 8080 : This basically does a lot of dynamic stuff and makes it behave as a SOCKS server. Of course you could use any non privileged port here (above 1023).
-f : This will fork the process into the background after you type your password.
-C : Turns on compression.
-q : Quiet mode. Since this is just a tunnel we can make it quiet.
-N : Tells it no commands will be sent. (the -f will complain if we don’t specify this).

So now that the tunnel is made we will need to configure Firefox to use this tunnel. Since we are cool we will dispense with the GUI config tool and just configure it directly. To do this open Firefox and type the following into the address bar:

about:config

You will see a LOT of config options so you will need to filter it a bit. Type “proxy” into the filter bar.

You will see something like this.

We are interested in these 6 items set to the following values:

network.proxy.no_proxies_on : localhost, 127.0.0.1, 192.168.0.0/24, .yourcompany.com
network.proxy.socks : 127.0.0.1
network.proxy.socks_port : 8080
network.proxy.socks.remote_dns : true
network.proxy.socks_version : 5
network.proxy.type : 1

network.proxy.no_proxies_on
This specifies which addresses etc. to NOT use the proxy (tunnel) with. At a bare minimum it should have “localhost, 127.0.0.1″. I added 192.168.0.0/24 as an example of the subnet address range I have at work. I obviously wouldn’t want to go through the tunnel if I am trying to get to a local address! That just wouldn’t work at all. The same would hold true if your company used a local DNS server to resolve host names of computers on your local subnet. In that case you would also want to add something like “.mycompany.com” which would NOT use the tunnel for any address in the “mycomnpany.com” domain.

network.proxy.socks
The IP Address of your SOCKS proxy (tunnel). In this case your local machine (127.0.0.1)

network.proxy.socks_port
The port number you assigned to the tunnel. 8080 in our example.

network.proxy.socks.remote_dns
This part is important because even though your traffic would be encrypted through the tunnel, that pesky sysadmin could still see you were doing DNS lookups for GirlsGoneWild.com! Setting this to “true” will send all your DNS traffic through the tunnel too. This feature is only supported on SOCKS5 so if your remote server only supports SOCKS4 then you’re out of luck with this feature.

network.proxy.socks_version
Self explanatory. Try to use version 5 if you can. If for some reason your remote server doesn’t support this version then use version 4 instead.

network.proxy.type
This basically turns all this stuff on or off. 1 = on. 0 = off. If for some reason you need to stop using a proxy then just set this to “0″. You can still leave all the other stuff set as it will just be ignored until you set this to “1″ again.

Well that’s it! Open Firefox and go to whatismyip. If you see the IP of your remote server then hallelujah THE MAN is finally off your back! If you see the address you usually get (the address of your company firewall) then something went wrong. Go back and double check that you did everything correctly. Also in a terminal check that your tunnel is still up.

ps -aux | grep ssh

If you don’t see the command you used to open the tunnel then it has closed and you will need to re-open it again.

Now back to the bit on the side. You can also configure MSN, Yahoo, AOL, Thunderbird etc. to use the same tunnel (no need for opening any more). Just go and configure their particular connection settings to use a SOCKS proxy too!

There’s a lot more that can be done from here like configuring things on the server for keeping the connection alive, as there are some cases where your network will cause things to time out. You could also setup your server to allow a key based login so you could have your tunnel open when you start up your computer. For now we have covered just enough to get you going without overloading on too many superfluous concepts.

Happy secure tunneling!

1f58″