Setting up an SSH Tunnel as a Proxy

There are 2 primary reasons you would want to SSH Tunnel:

• You are being blocked by a proxy at work, university, or some other controlled network.
• You want increased security over the wire.

When setting up an ssh tunnel, you’re merely routing traffic through a specific address and port. Seems pretty simple, and it really is, but you need to understand each part individually.

First I’ll be describing the SERVER side of things, then the CLIENT side.

Server

If you were looking to understand how to configure your system to use a proxy, then go ahead and jump to that section; this is for the server-side setup.

First thing you’ll have to do is configure openSSH-server. Depending on your OS, you’ll have to install it and generally doesn’t have much configuration for what we’re doing. I’ll list just a few:

Make sure you have a user on this system. In our case we’re going to assume the username remoteUser to log in with the password 123456. This will be used for when the user wants to log in and tunnel data through our… tunnel!

Client

This is the fun part, because all of the work is done here.

If you’re connecting to a server, then this is the spot you want to be at.
What the goal we want to achieve here is tell FireFox how to use your proxy. I chose to only discuss FireFox for multiple reasons; primarily because it’s cross platform, and has an extension system that makes this more specifically set up – not to mention it’s more secure.

There IS a step involved early though that requires the installation of OpenSSH client. Take a look at the server section, and see how I describe to install OpenSSH server, but you’ll want to install the Client package. Keep in mind that on Windows, they both come in the same package.

So now that OpenSSH is installed we need to execute it in a way that will forward our data to our remote server, on a specific port. For our use, we’ll be using port 1080, but anything above 1024 will suffice. I say above 1024 due to standards use; google for more info.

We’re going to assume our username is remoteUser and connecting the remote host name (or IP) of remoteHost.com.

To execute it, I copied the shortcut for BASH that the Cygwin installer made for me, and came up with the following:
[sourcecode language=”bash”]
REM File: %MYDOCS%/tunnel.bat
@echo off
C:chdir C:\cygwin\bin
nohup ssh -f -N -D 1080 [email protected]</pre>
[/sourcecode]

Most of that is what Cygwin put automatically, but instead of executing bash, I start executing ssh.

nohup is a binary that will stop your application from dying when the session ends (ie, closing of a terminal, etc). You can also, if desired, use screen to keep the session going and allow rejoining the terminal at a later date.

The ssh flags are used with a specific meaning as well:
-f Runs SSH in the background. Remove this to see all output and run “interactively” (ie, can kill easily).
-N Don’t execute your shell upon authentication. This is required.
-D The binding address is assumed localhost, and we’re specifying the port 1080. More on this later.

The rest is the user and host that we’re using to log in with. Get that from your admin, or whatever you set up in the server configuration. Test the connection by running the tunnel.bat file from your command line.

So now that we have the tunnel running, we need our browser to utilize it. You can do it the old fashioned way and set the browser to use the proxy, or you can use Firefox and FoxyProxy to configure when/how to use your proxy.

The gist is, you need to set up the proxy settings to the following (keep in mind that we’re following the values we established earlier):
Host: localhost
Port: 1080
Socks Enabled?: Yes, any version.

We are saying that we want to enable the Socks proxy to our own system over port 1080. Remember our Tunnel? We said we wanted localhost:1080 to route to our user@remoteName.

With FoxyProxy you have the ability to set up a basic or an advanced configuration. We’re going to take the approach of saying that we want to use the proxy for VERY specific traffic, only allowing a few websites to take advantage of our Proxy. There are a few other tactics you can implement to come up with a very advanced configuration.

Create a Pattern, and let’s call it FaceBook. This will contain the values for facebook.
Now we want our selection to be smart when it comes to picking our proxy. You ever notice sometimes a site like www.badsite.com is blocked, but say news.badsite.com isn’t? The admin didn’t do a good job at defining the domain pattern.
Here we create a RegEx pattern: https?://.*\.facebook\.com.* and set it to a whitelist value. Do the same for the rest of your blocked sites, or sites you don’t want anyone seeing you going to over the wire. Of course, if someone walks by, you’re on your own!