Introduction

This document describes how to set up SSH tunneling for connecting Agent to HVR Hub when Agent is hard to reach from Hub or if there are no routes open from Hub to Agent.

What Is Reverse SSH Tunneling?

Reverse SSH tunneling allows you to use that established connection to set up a new connection from your local computer back to the remote computer.

Because the original connection came from the remote computer to you, using it to go in the other direction is using it “in reverse.” And because SSH is secure, you’re putting a secure connection inside an existing secure connection. This means your connection to the remote computer acts as a private tunnel inside the original connection.

And so we arrive at the name “reverse SSH tunneling.”

How Does It Work?

Reverse SSH tunneling relies on the remote computer using the established connection to listen for new connection requests from the local computer.

The remote computer listens on a network port on the local computer. If it detects an SSH request to that port, it relays that connection request back to itself, down the established connection. This provides a new connection from the local computer to the remote computer.

Linux to Linux Remote SSH tunneling

In this scenario, both the Hub and HVR agent are running on Linux. I have server A which is designated to be HVR Agent and server B which is designated to be HVR Hub.

On Server A, the HVR agent is listening on port 4344. Inbound rules are allowed on ports 22 and 4344

On Server B, HVR Hub remote listener is listening on port 4345. Inbound rules are allowed on ports 22, 4344, and 4345

If SSH daemon is not started, start it using
sudo systemctl start sshd
Start HVR remote listener for Agent on port 4344

On Server A use -R (reverse) option to tell ssh that a new SSH session must be created on this server. 4344:localhost:4344 tells ssh that connection requests to port 4344 on the local computer should be forwarded to port 4344 on the remote computer. 34.234.85.156 is the IP for Server B

ssh -R 4344:localhost:4344 34.234.85.156

You may get a warning about having never connected to the local computer before. Or you may see a warning as the connection details are added to the list of recognized SSH hosts. What you see—if anything—depends on whether connections have ever been made from the remote computer to the local computer.

You will be prompted for the password of the account you are using to connect to the local computer. You can set up ssh keys instead of a password for authentication.

Because the connection from the remote computer is successful, and it is listening for connections, we can try to connect to the remote computer from the local one.

The remote computer is listening on port 4344 on the local computer. So—somewhat counter-intuitively—to make a connection to the remote computer, we ask HVR to make a connection to the local computer, on port 4344. That connection request will be forwarded to the remote computer.

Now test connect from HVR location

Windows to Linux Remote SSH tunneling

In this scenario both the Hub server is running on Linux and HVR agent is running on Windows 2016 Server. I have server A which is designated to be HVR Agent and server B which is designated to be HVR Hub.

On Server A, HVR agent is listening on port 4343. Inbound rules are allowed on ports 22 and 4343. This was configured on Windows firewall. On Windows, OpenSSH can be installed to initiate a remote tunnel. If OpenSSH is not installed, putty can be used to set up the remote tunnel

On Server B, HVR Hub remote listener is listening on port 4345. Inbound rules are allowed on ports 22, 4344 and 4345

On Windows server OpenSSH is installed and running as service
Open Powershell and set up tunnel using -R
ssh -R 4343:localhost:4348 -4 ec2-user@34.234.85.156
Please note, due to a bug with openssl, either use ipv4 using -4 or replace localhost with 127.0.0.1