SSH tunnelling made easy (part three)

In the previous two parts of this series, I covered simple tunnels to access services you couldn’t reach, and tunnels which let you hop from one server to another on an otherwise unreachable network.  In this article I’ll cover a powerful feature of SSH, the ability to provide port forwarding via the SOCKS mechanism.

SOCKS is a standard method to allow clients to connect to services via a proxy server.  SSH can turn any computer you can connect to (over SSH) into a proxy server for you, and you alone (so it’s secure).

Example 3 – using SOCKS proxy to access multiple services on a network via a secure server

There are several different reasons why you may need to employ SSH to deliver a SOCKS proxy.  Two common reasons are if you’re connected to a public network you don’t trust (like a cafe Wi-Fi network), or if you want to get to a range of services inside a secured network to which you only have SSH access.

Since the process is identical in both cases, I won’t cover them separately.

The diagram below shows a shared workstation (maybe in a library) connected to a public Wi-Fi network.  You can’t trust the network, anyone could be intercepting unencrypted traffic on it.

There is however a sever somewhere to which you have SSH access (and which in theory, you control and so trust).  What you would like to do is browse several websites or connect to some other SOCKS supporting services, without anyone on the public Wi-Fi being able to intercept that traffic.  If you were only connecting to a single service you could use simple tunnelling as per the previous two examples, but this time, you want to browse a few websites, and it’s not sensible to try and create a tunnel for each one.  In this instance, you use SSH to set up a dynamic tunnel, which provides a SOCKS proxy.

The command is even easier.

ssh -D

Similar to the previous commands, but you’ll notice there is no target destination, only a listening address and port.  The -D tells SSH to listen on port 9090 in this case, and operate as a SOCKS proxy, starting at the server you’ve connected to.

In PuTTY you would configure this as below,

Note that the destination address is left blank.

In order to use this tunnel, you need to do a little more work than previously.  Assuming we’re going to use it primarily for web browsing, you would need to tell your web client to use a SOCKS proxy.  In Firefox, you would configure it like this,

Now, when you try and browse anything in Firefox, it sends the requests to what it believes is a SOCKS proxy server (, port 9090).  That’s really your SSH connection to  At the other end, your SSH connection sends the data on to the correct web server, receives it, and passes it back to your workstation and into Firefox.

The net result (pun intended) results in a diagram which looks like this.

So your browsing is secure as far as the Public Wi-Fi is concerned.  SOCKS supports a number of different protocols, and different clients are configured in different ways.  But as long as your tool supports SOCKS, you can point it at the 9090 server, and it will work as above.

SOCKS via SSH is extremely powerful.  Here’s a further diagram of another situation where you may want to use it.

Your company has a number of web servers internally which provide time recording, project planning and other information.  While working away from the office you need to access those services.  There are too many to set up individual tunnels.  There is an SSH server in the company’s control which can be reached from the Internet.  Using the -D option, you can turn that server into your own SOCKS proxy and browse to the company web servers to complete your work.

While not intended as a replacement for a VPN (mainly because it only really supports a subset of network protocols), this SOCKS implementation is very useful.

3 thoughts on “SSH tunnelling made easy (part three)”

  1. Thanks for your very detailed guide, but can you explain in detail the difference between a plain ssh tunnel and an ssh tunnel with a socks server? I’ve found lots of guides like your on the internet, but none of them explain this difference. It seems like they do the exact same thing

    Also, if I create an ssh tunnel for my local computer to access the internet is the computer I’m sshing into actually sending and receiving all the information my local computer is sending/receiving or is it just establishing the connection to another source for my local computer, and then allowing my local computer to connect directly to that source without using my ssh server’s bandwidth. I ask because I’m paying $10 a month to get ssh tunnel access to a computer outside my network and there is no mention of bandwidth restrictions. If all my data requests are actually sent and received by the ssh server, it seems crazy that they would allow to eat up all their bandwidth for $10 a month.


    1. With a regular SSH Tunnel (parts 1 and 2) you are limited to a single destination. The tunnel goes from A to B.

      With a SOCKS tunnel, the destination is a single server, but that server in turn acts like a proxy allowing you to use the tunnel to connect to any service you like.

      If you use a tunnel, you send traffic through the tunnel to the other end, it travels somewhere else, comes back to the tunnel and then back to you. So yes, in the case of your $10 service, all of the traffic is leaving their network and going back to their network before travelling to you.

  2. I’m using Cygwin ssh and putty for my local pc (windows 2003 server installed ) still unable to hide the traces of browsing…do not understand why? I do not know where I went wrong…

Comments are closed.