Need to SSH to an unreachable Linux computer? Have it call you, then burrow down that connection to get your own remote SSH session. We show you how.
When You’ll Want to Use Reverse SSH Tunneling
Sometimes, remote computers can be hard to reach. The site they are located at may have tight firewall rules in place, or perhaps the local admin has set up complex Network Address Translation rules. How do you reach such a computer if you need to connect to it?
Let’s establish some labels. Your computer is the local computer because it is near you. The computer you are going to connect to is the remote computer because it is in a different location than you.
To differentiate between the local and remote computers used in this article, the remote computer is called “howtogeek” and is running Ubuntu Linux (with purple terminal windows). The local computer is called “Sulaco” and is running Manjaro Linux (with yellow terminal windows).
Normally you’d fire up an SSH connection from the local computer and connect to the remote computer. That isn’t an option in the networking scenario we’re describing. It really doesn’t matter what the specific network issue is—this is useful whenever you can’t SSH straight to a remote computer.
But if the networking configuration on your end is straightforward, the remote computer can connect to you. That alone isn’t sufficient for your needs, however, because it doesn’t provide you with a working command-line session on the remote computer. But it is a start. You have an established connection between the two computers.
The answer lies in reverse SSH tunneling.
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.
It’s easier to set up than it is to describe.
Using SSH Reverse Tunneling
SSH will already be installed on your Linux computer, but you may need to start the SSH daemon (sshd) if the local computer has never accepted SSH connections before.
sudo systemctl start sshd
To have the SSH daemon start each time you reboot your computer, use this command:
sudo systemctl enable sshd
On the remote computer, we use the following command.
- The -R (reverse) option tells ssh that new SSH sessions must be created on the remote computer.
- The “43022:localhost:22” tells ssh that connection requests to port 43022 on the local computer should be forwarded to port 22 on the remote computer. Port 43022 was chosen because it is listed as being unallocated. It isn’t a special number.
- firstname.lastname@example.org is the user account the remote computer is going to connect to on the local computer.
ssh -R 43022:localhost:22 email@example.com
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.
Note that when the connection has been made the command prompt changes from dave@howtogeek to dave@sulaco.
We’re now connected to the local computer from the remote computer. That means we can issue commands to it. Let’s use the who command to see the logins on the local computer.
We can see that the person with the user account called dave has logged in to the local computer, and the remote computer has connected (using the same user credentials) from IP address 192.168.4.25.
Connecting to the Remote Computer
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 43022 on the local computer. So—somewhat counter-intuitively—to make a connection to the remote computer, we ask ssh to make a connection the local computer, on port 43022. That connection request will be forward to the remote computer.
ssh localhost -p 43022
We are prompted for the user account password, then connected to the remote computer from the local computer. Our Manjaro computer happily says, “Welcome to Ubuntu 18.04.2 LTS”.
Note that the command prompt has changed from dave@sulaco to dave@howtogeek. We’ve achieved our goal of making an SSH connection to our hard-to-reach remote computer.
Using SSH With Keys
To make it more convenient to connect from the remote computer to the local computer, we can set up SSH keys.
On the remote computer, type this command:
You will be prompted for a passphrase. You can press Enter to ignore the passphrase questions, but this is not recommended. It would mean that anyone on the remote computer could make an SSH connection to your local computer without being challenged for a password.
Three or four words separated by symbols will make a robust passphrase.
Your SSH keys will be generated.
We need to transfer the public key to the local computer. Use this command:
You will be prompted for the password for the user account you are logging in to, in this case, firstname.lastname@example.org.
The first time you make a connection request from the remote computer to the local computer, you will have to provide the passphrase. You will not have to enter it again for future connection requests, for as long as that terminal window remains open.
#1 on 2019-Ott-26 Sab 10:02+7200
#2 on 2019-Ott-26 Sab 10:29+7200
#3 on 2019-Ott-26 Sab 10:10+7200
#4 on 2019-Ott-26 Sab 10:47+7200