DEV Community

Cover image for SSH Tunneling: the Good, the Bad, and the Ugly

Posted on • Originally published at

SSH Tunneling: the Good, the Bad, and the Ugly

SSH tunnels are a well-known measure to securely forward connections to a remote machine. In most cases, SSH is fast, easy to setup, and easy to use, but it’s not without it’s drawbacks. Learn what they are in this blog.

Many developers know SSH tunnels inside out – many times they’re a prerequisite to working remotely, and sometimes they’re a necessity to complete work with websites, applications, or databases supporting them. Whatever the case, SSH tunneling is a method of working with data remotely via an SSH connection – and SSH is also commonly used as a method to create secure tunnels between different servers.

What Is an SSH Tunnel and SSH Tunneling?

In simple terms, a SSH tunnel is a method of working with data over SSH – short for a Secure Socket Shell (also sometimes called Secure Shell.) SSH is a way to securely access a server over an unsecured network.

Many companies use SSH, and the use case of SSH tunnels varies from company to company – some companies use SSH to access internal data to support their marketing, software engineering, security, or other efforts, some use SSH tunnels for interviews to grant people access to remote Amazon AWS servers for them to work with data to complete a task and provide a report on what they‘ve accomplished, some use them for other tasks.

However SSH tunnels are being used, their core premise remains the same – they provide people with a way to securely access their most precious data: a simple image would illustrate the concept of an SSH tunnel (8080, 22, and 80 are ports) – in this case, server #1 reaches the server #3 through server #2 (note that the port with which server #2 is accessed is no longer 8080 or 80 – it’s 22 meaning it has been accessed through SSH):

Illustration of what an SSH tunnel is.

Illustration of what an SSH tunnel is.

Security and SSH – the Downsides

As you might have understood, the core concept of SSH is the communication of two servers in an encrypted manner. In other words, the concept of SSH is secure communication, but SSH also has a couple of downsides that must be considered:

  1. Technical knowledge – the first and foremost problem of SSH is that it requires quite a bit of technical knowledge to operate and to get to work correctly. Before embarking on their SSH journey, people must know how to generate SSH keys, then copy the SSH keys over to the server they’re going to access, know what SSH key they’re going to use to access a server, what server are they going to access, and does the server support SSH connections in the first place. Sounds like a hassle, doesn’t it? Now imagine that you didn’t have any technical knowledge in the first place – how complex would it all be?
  2. No GUI – the work with data over SSH is pretty dull, really: it’s all commands and issuing technical instructions to a server without any interface, and for some, not having a clear and concise GUI is a really big turn-off. For experienced engineers, though, that’s not that big of a deal, it’s just that people need to get used to such things before working with them.
  3. Not everything works through SSH – in this day and age, you would suspect that everything connected to the web would be accessible through SSH, but that’s only possible if the server supports port 22 (a secure version of the port 21), and if the server was previously configured to be accessible through SSH in the first place.
  4. The management of SSH keys is sometimes problematic – since SSH supports logging in with encrypted keys that must be generated beforehand, the management of them sometimes gets out of hand even for the most security-conscious organizations and individuals. In a large organization, having hundreds of keys to access hundreds of servers isn’t out of the question – what is concerning, though, is the ability of companies to manage them all. Imagine having hundreds of keys to access hundreds of servers: does that sound like fun? Oh, and only one key is a fit to access a server. Good luck identifying which key belongs to which server! Did we tell you that SSH keys must be added to a server before the server can be accessed via SSH too?
  5. IT departments don’t fully understand SSH – some say that the majority of problems associated with SSH is the mismanagement of their keys by IT departments. Why? The answer may be related to the fact that IT departments are not necessarily well-versed in servers: we all should remember that IT departments employ all kinds of people – from sysadmins to simple “helpers” that are tasked to help other employees working on the same product to solve issues. Not all people in IT departments might understand the significance of SSH, and consequently, not everyone might manage their SSH keys in a safe and secure way.
  6. SSH can be slow to respond over metered connections – for some, a problem might arise when SSH is used for high-intensity bandwidth commands over metered connections too. Can you imagine using the wget command to download a 500GB file over a 10mbps connection? Yeah, painful.

Reverse SSH Tunnel

Once you’ve considered all of the upsides and downsides posed by SSH, you might also be interested in functionalities related to SSH. One of such functionalities is the reverse SSH tunnel – a tunnel is frequently used to access an office PC from home, for example.

The concept of reverse SSH tunneling is establishing connections backwards – for example, from server B to server A instead of the other way around.

To create a reverse SSH tunnel, connect to a remote server using SSH like so:

ssh [username]@[serverip]
Enter fullscreen mode Exit fullscreen mode

Then on the server B, run something like this:

ssh -fN -R 777:localhost:23 username@ipaddress
Enter fullscreen mode Exit fullscreen mode


  • 777 is the port of the local machine that moves to port 23 of the remote server.
  • username is the username of the remote server you want to access and the IP address is the IP of the server you’re trying to access as well.

Once done, make an SSH connection request to the remote machine you want to access in a simple manner you’re used to, just make sure to specify the port like so (the port 777 will be forwarded to the port 23):

ssh username@localhost -p 777
Enter fullscreen mode Exit fullscreen mode

You’re done!

Take note of the points mentioned above – before considering using SSH in any of your projects or at work, make sure to weigh each and every one of them very carefully, then decide if SSH is the option for you, and if it is, use it properly to avoid mishaps – this guide will guide you through most of the things you need to know, but the rest is up to you to figure out.


In this blog, we have walked you through the basic concept of SSH tunneling – we have walked you through what it is, how to work with it, and what problems can it cause to users when used improperly.

Take from this blog what you will, and make sure to test the advice you got from this blog before trying anything in a production environment. If you’ve enjoyed this article, make sure to stay around the DbVisualizer blog to learn more about databases, web development, and servers as well.

About the author

Lukas Vileikis is an ethical hacker and a frequent conference speaker. He runs one of the biggest & fastest data breach search engines in the world -, frequently speaks at conferences and blogs in multiple places including his blog over at

Top comments (0)