In a previous post I covered how I’ve been using PuTTY to get through the day, I decided to expand on it a little further and document a couple steps to bring a particular server’s ports closer to you … even if they’re firewalled away.

An ssh tunnel can be explained quite simply as:

an encrypted connection that is used to transport another protocol

Single Server

sshing into a server is one thing, but what if port 22 is the only practical accessible port due to firewall restrictions? To connect to a database on the server one can use a tunnel to “sneak” through.

To expand on this example further, let’s say there’s a postgres server running on port 5432 but the firewall is blocking access to it (as it probably should be). It is trivial to setup an ssh tunnel to effectively bring the port to the local machine.

Using PuTTY, configure the connection as per normal, for example:

Then in the SSH settings, add a port value for the Source port field, this is the port you’ll need to use in your database tool of choice, pgAdminIII perhaps. This can be any port really, except for anything already in use locally, i.e. if you’ve got postgres running locally, don’t choose 5432.

In the Destination field, this is the important bit, set the host:port combination as though you were directly sitting at the remote server, i.e. localhost:5432 for the server’s local database.

Once you open the session, the tunnel is live too. One can now go into pgAdminIII and setup a connection to a local database:

Note the port in use and that the host is localhost as it is connecting to the local end of the SSH Tunnel on the configured port 15432.

pgAdminIII has an option to configure an SSH Tunnel in the connection creation dialog but I haven’t worked out how that fits in to the picture just yet.

So there’s a connection, does it work?

As a side note: if you close your PuTTY session, your tunnel will go with it.