Happy SysAdmin day everyone! While my title may not say “System Administrator” any longer (although, my business cards do… probably need to change them), I still wield those skill all the time and have utmost respect for those in the trenches.
I thought today would be a great time to bust out a post on what I believe to be the most useful tool in my Sys Admin belt… SSH Tunneling. 
SSH Overview
SSH (aka – Secure Shell) is a network protocol that allows connections to network connected devices. SSH sessions are encrypted, so your communications to and from the devices are safe. Typically, SSH connections are seen in Linux-based, UNIX-based, and Networking devices.
Contrast SSH to Telnet… while they provide many of the same functions (ex: remotely connecting to a device), the Telnet communications are plain text and wide open. So, when logging into a server and providing your password, someone with a packet sniffer (WireShark, for example) would see something akin to:
SSH: B12394jfjLL1055bSSJxla,;;293
Telnet: thisismysupersecretpassword
SSH Tunneling Overview
While SSH allows for remote connections to devices, that is not the only function it can provide. Tunneling is a little option available that actually uses the SSH connection to a remote device as a launching point to get into another device or service. When the SSH connection is made to the device, a new connection to specific hosts and TCP-based services are also made and tunneled back to you.
For those of you that have not used SSH port forwarding, the concept may be a little funky. So, please read on and learn about the coolness that is SSH tunneling. For those that use the functionality now, I hope you continue to use it wisely and appropriately… and read on for a refresher if you’d like.
The Nitty Gritty
[Note: this is all hypothetical. If you have security restrictions/policies in place, I do not suggest your using this. This is just an example of how the technology works. It is up to you to figure out how to use it in your life]
This is my “environment”. This is overly simplistic, but should get the point across.
As mentioned earlier, SSH tunneling uses the connecting host as the launching pad for the tunneled connections. When a successful connection to the SSH target is made, the specified connections are also plumbed between your workstation/client and the destination.
Once a connection is established by you, the destination will see a connection from the SSH launch pad. You will see a port on your local workstation/client as a localhost connection.
Scenario
You’re visiting your in-laws in Ohio. For whatever reason, you need to check something at work on the Linux2 server. . All you have available is a non-work Windows desktop. Without a VPN connection or remote desktop client installed, how can you check on the thing? SSH tunneling through Linux1! Let me show you how.
- Download PuTTY (Fantastic utility. I would probably die without it).
- Start PuTTY
- Provide the Host Name or IP of the Linux1 server
- Walk down the Category section on the left and go to: Connection –> SSH –> Tunnels
- This is where the magic happens. In the source port, enter the TCP port that will represent the tunnel on localhost.
- This requires you to know what is running on the workstation. Do not chose an existing port as the SSH connection will be successful, but the tunnel will fail.
- In the destination section, enter the target of the tunneling (aka – what you’re trying to get to) AND the TCP port of the service in the following format: linux2.yourdomain.com:80
- The destination tunnel endpoint will utilize the SSH host resources you are connecting to. So, DNS resolution of linux2.yourdomain.com will take place from linux1, not your workstation.
- I am going to select Source of 22222 and Destination of linux2.yourdomain.com:80
- Click the Add button
- Now, if you want other tunnels, you can add them here as well. But, we’re just going to move on. Click Open to open the SSH connection and login.
- Once you have logged in, you can use ‘netstat –anp tcp’ to show the TCP connections on your workstation:
- Magic! You can see that I have a TCP:22222 listening on my workstation.
- Now, it is time to check that super important thing you are trying to check on. Since we know this is a web-based utility, we just need to open a web browser and browse away. Open your browser-du-jour.
- Go to http://localhost:22222/superimportant
- Phew! Looks everything looks alright… Time to cleanup!
- Close the browser window and logout of the SSH session.
- If you run the ‘netstat –anp tcp’ command again, TCP:22222 is missing.
- If you try and go back to http://localhost:22222/superimportant:
Conclusion
Sys Admins have a great arsenal of tools available to them at any given point in time. SSH Tunneling has provided massive functionality to me in my day job. I hope that you find some value in SSH tunneling and can add it to your tool belt for those visiting the in-law moments.
