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. 188.8.131.52 is the IP for Server B
ssh -R 4344:localhost:4344 184.108.40.206
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 email@example.com
Please note, due to a bug with openssl, either use ipv4 using -4 or replace localhost with 127.0.0.1
Now the tunnel is ready, we can connect back to HVR Agent on Windows server with the SQL Server database.
Test connection using HVR.
After creating the location, run table explore and select the tables.
If you don’t have OpenSSL installed, the Putty can be used. Putty configuration is as below