Use cases for SSH tunneling (port forwarding)

SHH tunneling, as you might know, allows for transferring data through an encrypted channel. The data being transferred itself may or may not be encrypted. Setting up these tunnels is actually an easy process. But let’s briefly discuss how SSH works first.

SSH stands for “Secure Shell” and is simply a protocol for secure communication. This is commonly used by people to access their servers. On the server side, there is a program like OpenSSH that listens on port 22. On the client side, there is a program such as PuTTY that connects to the server through the given port. The two authenticate through means such as passwords and/or keys. Once this is done, the client is given access to the default shell for the target user and any communication that occurs is encrypted with what’s defined in the SSH protocol.

Back to SSH tunneling. The three types are dynamic, local, and remote. To help you understand the usefulness of each, I will go through three example use cases.


Facebook is blocked at my school. I WANT FACEBOOK!!!

Let’s make this more generic and say you want to access any blocked website on your local network. Being blocked essentially implies that your network activity is being monitored. With the help of dynamic tunneling, you can access any blocked content (provided your server has access to it), and pretty much conceal your network activity to the point where the only thing that can be known by your network administrator or an adversary is that you’re having communication through the SSH protocol.

So how can you can you set up these? In your client program, look for something like “Tunnels” or “SSH port forwarding”. In PuTTY, you’ll find this section in Connection -> SSH -> Tunnels. Under “Add new forwarded port”, select “Dynamic”. For the IP type, leave at “Auto”. For the “Source port”, put down a port that you computer is most likely not utilizing like 32568. The port is limited to 16-bits, meaning the maximum number is 65535. For the destination, leave empty as we want this forwarding to happen through the local interface (i.e. localhost). Click on “Add” and connect normally.

Once you’re done, open up your browser such as Chrome and head over to the settings page. Look for the proxy connection section and set the Socks to be localhost:32568. You can now browse the web securely…well at least like your server and its network.

What if you want to secure the network activity of any application, one that may not support setting the Socks server? Well for that, Google “socksifier” and pick one.


I want to access VNC running on my server securely!

VNC (Virtual Network Computing) is a popular way of accessing your computer desktop remotely. It works through the RFB (Remote Framebuffer) protocol, which is NOT a secure protocol. Let’s say that you have a window system such as X running on your Linux server. If you want to access it through the network on another computer, what you might do is run a program on your server such as TightVNC. TightVNC server will listen on a port like 5901, on maybe the LAN interface like eth0. On your main computer, you’ll run TightVNC client to connect to the server given the network address and port. After maybe authentication, you’ll essentially have access to your server’s desktop! The problem is, what if you’re main computer is on a network that can easily be monitored?

An adversary can easily capture and possibly decrypt your VNC password. However, that’s not all. The data being sent for you to be able to control the server’s desktop is not encrypted. This effectively means the adversary can monitor and maybe even modify what occurs in your VNC session. Not good.

Thankfully, with SSH local port forwarding, you can rest assured of privacy. First what you should do is have the TightVNC server listen on the local interface. A command such as the following should do the trick:

tightvncserver -nolisten tcp -localhost :1

What this does is tells TightVNC to listen on port 5901 for the local interface. This means you will no longer be able to VNC through simply the server’s address and that port from your main computer.

Now that you have this set up, go to your SSH client and find the tunneling section again. Set the type to be “Local”. For the “Destination”, set it to be “localhost:5901″. For the “Source Port”, set it to something like 5910. Add it and connect as usual. Now, to access the server’s desktop, in your VNC client, set the target to simply be “localhost:5910″. You should notice that you are able to connect like before, only now you’re doing it very securely!


I’m at college. How can I allow my friend from his college network to access an application running and accessible to only my college network?!?

If you consider yourself to know anything about college networks, you’ll know that firewalls play a crucial role. In my college network for example, incoming connections from outside the network are blocked by default for most clients. The only way to go around this is to ask for a firewall exception. However, for the sake of this example, let’s say you don’t have that privilege and neither does your friend. So how can you get this to work?

Well since neither you nor your friend can contact each other directly, one option is to have a third node that’s accessible by both you and your friend. For example, that Linux server you have lying around.

Let’s say the application you want your friend to access is accessible by you through the following address “″. Go back to your SSH client and find the tunneling section. This time, set the type to be “Remote”. For the “Destination”, set it be “″. For the “Source Port”, set it to something probably not being used on your server like 5329. Add this and connect as usual.

Your friend should now be able to access the application through YOUR_SERVER_ADDRESS:5329. Awesome! If this does not work, the most likely reason for it is that the OpenSSH server running on your server is listening on port 5329 for only the local interface. To change this, open up your SSH daemon config file, which is probably the following:


Look for “GatewayPorts”. If it exists, set it to “yes”. If it doesn’t, simply add it. It should look like the following:

GatewayPorts yes

Save and restart the SSH server. Connect again with your SSH client while making sure the port forwarding is still set. This should now work!


Note (s):

Don’t have a Linux server? No problem. Amazon will give you one for FREE! Check out AWS Free Usage Tier.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>