Use SSH to Cross a Suspect Host Securely

SSH tunnels can be used to connect securely to a server behind a firewall in such a way that the firewall can't observe the data. This is also true and useful if you know an attacker has gained control of the firewall.

If Netbook has a public IP, you also can set up a reverse tunnel from Server to Netbook. The reverse tunnel allows you to connect to Netbook from Server and then connect back to Server via the reverse tunnel. If the reverse tunnel doesn't need to go through Gateway, you then could take Gateway down for investigation and repair while still being connected to the internal network. See the Reverse SSH Tunnel sidebar for more information about reverse tunnels.


Connect to your possibly compromised machine, Gateway, and create a tunnel to the machine you ultimately want to reach, Server. Once the tunnel is up, use it to connect to SSH on Server:

ssh -a -N -f -L 3333:Server:22 Gateway
ssh -P 3333 localhost


  • Don't forget to block authentication agent forwarding.

  • Don't forget to specify remote user names if you need them.

  • Use a port above 1023 if you're not connecting as root.

  • Make sure to have confirmed SSH host keys previously.

  • Add the host key to your known_hosts file as an entry for localhost, because SSH will see the connection as being to localhost.

  • Use -D to create a SOCKS proxy.

  • None of the commands in this article require root access. All would work from your own account.

  • The attacker can block the connection and can control the connection to Gateway, but the attacker can't compromise the connection to Server.

Any SSH connection across the Internet is crossing questionable hosts/routers. If those were safe, you wouldn't need a secured connection. The tunnel is the same scenario, because it's just enabling a normal SSH connection.

der.hans is Vice President of Engineering at a startup in stealth-mode, cofounder of TwoGeekTechs, founder of the Free Software Stammtisch, an adjunct instructor at a local community college, Chairman of the Phoenix Linux Users Group, strategic advisor to TEDxPhoenix and founding member of League of Professional System Administrators (LOPSA). In his free time, he likes to go camping, annually not set himself on fire and brag about his grandma's cheesecakes and Spätzle. He can be reached via



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"you can ssh safely across a

Anonymous's picture

"you can ssh safely across a compromised host"

You keep using that word. I do not think it means what you think it means.

Not so troubling

lufthans's picture

WARNING: Anything communicated to authenticate to a compromized host could potentially be captured by the attacker and used against other hosts.

As the author, I do not mean for my article to dismiss the importance of shutting down a compromised host. The article explains that you might need to temporarily hop through the compromized host and describes how to do so safely.

I agree in pulling a machine off the air and even specify doing so in the 3rd paragraph. As a sysadmin I realize there are often steps to take before doing so. This article describes a way to safely connect to the internal network if needed, even if it's not the best position to be in.

The authentication credentials for the bastion host and the chewy center of your network should be different :).

I warn against forwarding agent connections through the compromized host. I also cover safely verifying the internal server's host key.

I see that I did leave out specific warnings about authentication credential ( such as personal key and password ) reuse. You are correct, if they are the same on both Gateway and Server the attacker could gain the credentials when you connect with Gateway and then use them on Server. I should have covered that in the article.

WARNING: Anything communicated to authenticate to the Gateway could potentially be captured by the attacker and used against other hosts.


The article does not pretend there are no security risks at all and specifically warns against a couple.

I generally believe bastion hosts on the edge of the network should be treated as if they could be compromized any minute. The methods in this article allow access to network resources without giving the bastion host access to those resources even if it's the gateway to reach them.

Very Troubling Article

Anonymous's picture

This article does a fine job of explaining ssh tunneling. However, I am troubled by two issues with the technique suggested by the author.

First, that the author simply dismisses the importance of immediately removing a suspect host from the network. This is a red flag to be highly skeptical of any security advice to follow. Best practices are ignored at one's own peril.

Second, the omission of any discussion of the risks of establishing an ssh connection to the compromised host.

Yes, the tunneled ssh connection is not much different than an ssh session crossing unknown internet hosts. However in order to create that tunnel, one must first authenticate to the compromised host. This risks of this cannot be understated.

Well known are many rootkits which alter or replace sshd in very nasty ways. At a minimum, you are handing over your authentication credentials. By establishing a tunnel to an internal host you are potentially alerting your attacker to another target of interest which may accept those credentials.

The entire tone of the article presents the author's tunneling technique as if it involved no security risks at all. This is simply not true. The security best practice in this case is well established: Never open a network login to a compromised host.