Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

SSH Tunnel

This page explains what SSH tunneling (also called SSH port forwarding) is, how it can be used to get into an internal corporate network from the Internet, and how to prevent SSH tunnels at a firewall. SSH tunneling is a powerful tool, but it can also be abused. Controlling tunneling is particularly important when moving services to Amazon AWS or other cloud computing services.

What is an SSH tunnel

SSH tunneling is a method of transporting arbitrary networking data over an encrypted SSH connection. It can be used to add encryption to legacy applications. It can also be used to implement VPNs (Virtual Private Networks) and access intranet services across firewalls.

SSH is a standard for secure remote logins and file transfers over untrusted networks. It also provides a way to secure the data traffic of any given application using port forwarding, basically tunneling any TCP/IP port over SSH. This means that the application data traffic is directed to flow inside an encrypted SSH connection so that it cannot be eavesdropped or intercepted while it is in transit. SSH tunneling enables adding network security to legacy applications that do not natively support encryption.

Securing applications with ssh tunneling / port forwarding

The figure presents a simplified overview of SSH tunneling. The secure connection over the untrusted network is established between an SSH client and an SSH server. This SSH connection is encrypted, protects confidentiality and integrity, and authenticates communicating parties.

The SSH connection is used by the application to connect to the application server. With tunneling enabled, the application contacts to a port on the local host that the SSH client listens on. The SSH client then forwards the application over its encrypted tunnel to the server. The server then connects to the actual application server - usually on the same machine or in the same data center as the SSH server. The application communication is thus secured, without having to modify the application or end user workflows.

The downside is that any user who is able to log into a server can enable port forwarding. This is widely exploited by internal IT people to log into their home machines or servers in a cloud, forwarding a port from the server back into the enterprise intranet to their work machine or suitable server. Hackers and malware can similarly use it to leave a backdoor into the internal network. It can also be used for hiding attackers's tracks by boucing an attack through multiple devices that permit uncontrolled tunneling.

To see how to configure an SSH tunnel, see this example. Tunneling is often used together with SSH keys and public key authentication to fully automate the process.


SSH tunnels are widely used in many corporate environments that employ mainframe systems as their application backends. In those environments the applications themselves may have very limited native support for security. By utilizing tunneling, compliance with SOX, HIPAA, PCI-DSS, and other standards can be achieved without having to modify the applications.

In many cases these applications and application servers are such that making code changes to them may be impractical or prohibitively expensive. Source code may not be available, vendor may have gone bankrupt, product may be out of support, or the development team has left. Adding a security wrapper, such as SSH tunneling, has provided a cost-effective and practical way to add security for such applications. For example, entire country-wide ATM networks run using tunneling for security.


As useful a thing as SSH tunneling is, it also includes risks that need to be addressed by corporate IT security teams. SSH connections are protected with strong encryption. This makes their contents invisible to most deployed network monitoring and traffic filtering solutions. This invisibility carries considerable risk potential if it is used for malicious purposes such as data exfiltration. Cybercriminals or malware could exploit SSH to hide their unauthorized communications, or to exfiltrate stolen data from the target network.

In an SSH back-tunneling attack, the attacker sets up a server outside the target network (in Amazon AWS, for example). Once the attacker is in the target system, he connects to the outside SSH server from the inside. Most organizations permit outgoing SSH connections, at least if they have servers in a public cloud. This SSH connection is set up with an option that enables TCP port forwarding from a port on the external server to an SSH port on a server in the internal network. Setting up this SSH back-tunnel requires a single one-line command on the inside, and it can easily be automated. Most firewalls offer little to no protection against it.

SSH port forwarding attack using SSH tunneling

There are several widely known and documented cases of malware leveraging the SSH protocol as a means for hiding data exfiltration and command channels. Several instances of malware have been actively collecting SSH keys. Captured and collected SSH keys have also been sold on hacker forums.

Combined with attacks based on unmanaged SSH keys, SSH tunneling allows an attacker to utilize stolen SSH keys for the Intranet from the public Internet.

SSH tunneling attacks can also be used for hiding the source of the attack. It is common or hackers to bounce attacks off systems and devices that allow SSH port forwarding to hide their tracks. This allows them to probe for vulnerabilities, try various login credentials, or run attack tools against email, web, telephony, and any other protocols. Bounching an attack through a dozen random devices via encrypted tunnels also carrying other traffic makes it virtually untraceable. Akamai recently documented millions of IoT devices (Internet of Things, i.e., smart devices connected to the Internet) being used in this fashion.

Countering these risks requires the capability to monitor, control, and audit encrypted SSH connections. For preventing bouncing, it requires proper configuration an hardening of IoT operating systems by the manufacturer, which we can help with.

It should also be noted that tunneling attacks are not specific to SSH - a competent programmer can write a tool to tunnel ports in a few hours and can run it on any machine on the internal network. Any laptop or other device on the internal network can do it - it just needs to be able to communicate with some (any) service on the Internet. The tool could be made to work over SSL/TLS, could emulate HTTP, or could operate over UDP and use packets that look like DNS requests and responses. SSH just makes it easier for non-programmers. You can only protect from tunneling attacks against people who are able to run software on the inside or connect any device to the internal network by only allowing protocols you can inspect through the firewall.

Preventing unauthorized SSH tunnels

CryptoAuditor® is a network-based solution that can prevent unauthorized SSH tunnels at a firewall. It can decrypt SSH sessions at firewall based on policy, using access to host keys. It can also control file transfers, record sessions for forensics and internal audit, and pass encrypted session contents to data loss prevention, analytics, and intrusion detection systems (IDS). For more information, see the CryptoAuditor page.

How to configure an SSH tunnel

See the configuration example page for detailed configuration instructions. The SSH command line options and SSH server configuration file pages may also be helpful.