How to access your home or work Linux computer behind a NAT network using a reverse SSH channel

botond published March 2019, 01, Thu - 10:02 time

Content

 

Introductory

Nowadays, there is an increasing need to be able to access your home or work computer from anywhere, to move / sync files to your mobile phone, or to run commands on your home / work computer, from anywhere. There are many ready-made solutions for this in the form of better remote control or data synchronization programs, and even free versions, where you can easily manage the desktop of the configured remote machine from the other machine or mobile, or even synchronize files with them. It’s all beautiful and good, but they all have the same problem: we can only use them for what they were made for. Remote desktop connection, file transfer, or touchpad function from mobile.

But what if we want to use the connection in a unique way, either automated over the connection without using a graphical interface, or just to open a protocol-level data channel remotely from our computer to exchange data with other devices or programs? It's not that easy anymore because most ISPs are depleting IPv4 addresses NAT (Network Address Translation) places the end points of a residential Internet connection behind a network, which is like having multiple subscribers behind a large router. This means that smaller groups of subscribers share the same public domain IP addresses to get them online. Or a company firewall is stopping by to access the machines behind it. Whatever the situation, it becomes difficult to access the desired computer from the open Internet.

It could still be up to him with simple port forwarding, but if we want to access a machine behind a multi-embedded (router, firewall, etc.) network "from outside", then port redirection can be a problem. But luckily there is a solution!

In this description, one is reverse SSH tunnel let's build one SSH a connection that allows us to access the destination computer at any time, whether it's behind any router or firewall.

 

 

Prerequisites

This setup is done on Linux, so you will first need a home or work computer running Linux. There are also separate SSH tunneling programs for Windows, but in this description we only deal with setting up Linux. If you still want to access your home Windows machine from the outside world, you may want to install a Cygwin system, which should be downgraded to the minimum possible level (SSH, SSHd, default) shell commands, etc.) so as not to consume a lot of resources. The rest of the description will then work in it. Hereinafter referred to as this machine home computer.

Second, we will need a live SSH access that is available from anywhere on the Internet. This can be a dedicated server housed in a server park or a leased server, or a monthly approx. 1000 forints VPS service, on which we have root access. But it could even be a Linux computer with an acquaintance connected to a fixed IP address and we can interrogate it to request an SSH access. This is called a server with SSH access mediation server.

And finally we need a computer or a mobile phone, tablet, etc. that can be anywhere on the internet, the point is to be able to initiate an SSH connection from it, after all, that would be our goal to access your home computer from anywhere via SSH. This is called from here client computer.

In addition, a SSH login without password Set up from your home computer to the proxy server for later automatic connection.

 

Principle of operation

For the sake of greater transparency, let us first briefly outline the working principle of the whole. Here are the three ingredients listed below that have the following roles:

Az from your home computer opening an SSH tunnel in mediation server. Outside, you can use SSH anywhere without any problems. Through this open SSH tunnel a mediation server you can connect backwards anytime home computer. That's why it's called a reverse SSH tunnel. And since the mediation server is accessible from anywhere on the Internet, so from client computer we can connect to it. From here, only the mediation server you need to open a new connection back to home computer then forward the traffic between the two machines.

Incidentally, VPN networks and the above-mentioned remote control, file synchronization programs that use their own servers as a proxy server work on this principle. So now we are setting up our own network like a VPN.

 

Set up a connection

When setting up the connection, we use several parameters that remain the same until the end of the description. Therefore, we now define them here:

  • The IP address of the proxy server should be 100.100.100.100
  • You will also need a port that we will redirect during the broadcast, which should be 12345
  • Be a home computer user otthoni_felhasznalo
  • And the user to be used on the mediation server kozvetito_felhasznalo

So in the future, I will use these parameters to make the settings so we don't mix them. Here, everyone should replace their own IP address, port number and user names.

While making this description, I make these settings with my desktop (home computer with NAT-DIGI net + router), my own leased server (proxy server), and my mobile phone (set to mobilnet) (client computer) with my own parameters, where I will go from mobilnet to access my home machine. That way I can guarantee that things work.

Establishing a reverse SSH tunnel

First, we open a reverse SSH tunnel from the home computer to the proxy server. For that, it is ssh command.

On your home computer it is otthoni_felhasznalowith the following command:

ssh -fN -R 12345:localhost:22 kozvetito_felhasznalo@100.100.100.100

Where the switches and parameters are as follows:

  • -fn: Put the ssh command in the background and not run any commands on the proxy server. Use only for port redirection
  • -R 12345: localhost: 22: This defines the reverse SSH tunnel: Forwards port 12345 of the proxy server to port 22 of the local machine (home computer). If you use a different SSH port 22 on your home machine, of course we will use it. Also, make sure that the port number 12345 I selected here is not in use by other programs, because then another port must be selected.
  • kozvetito_felhasznalo @ 100.100.100.100: This, of course, defines the connection to the proxy server for kozvetito_user.

If you use a different, unique SSH connection port on your proxy server (for added security) from the default port of 22, insert the -p switch:

ssh -fN -R 12345:localhost:22 kozvetito_felhasznalo@100.100.100.100 -p <egyedi portszám>

If the command is executed successfully, we will immediately get the shell back. Of course, you need to work with the above mentioned SSH login without passwordto go to the proxy server without user intervention.

Then, go to the proxy server and netstat command to verify that the redirect has actually occurred:

sudo netstat -nap | grep 12345

If it works, the output should look like this:

tcp   0   0 127.0.0.1:12345    0.0.0.0:*      LISTEN    14377/sshd: kozvetito_felhasznalo

 

 

Reverse SSH Tunnel Closure

If necessary, we can close the connection from any end of the SSH tunnel at any time.

To terminate the connection from the proxy server:

To terminate it on the proxy server, we can close the SSH tunnel with the command issued on the proxy server by firing the process ID from the previous netstat command:

kill 14377

To end a connection from your home computer:

And if you want to break the SSH tunnel on the other side, ie from your home computer, you must first find the process ID of the SSH command running in the background:

ps -x | grep 12345:localhost

The -x switch is also used to get the processes running in the background. It outputs something like this:

3191 ? Ss 0:00 ssh -fN -R 12345:localhost:22 <kozvetito_felhasznalo>@100.100.100.100

Then shoot the resulting PID:

kill 3191

However, do not close the channel or reopen it yet, as we will be working on it.

Connect to a NAT-hosted machine by moving to the proxy server

From now on, if you access the proxy server from anywhere, you can log in to your home computer using the command on the proxy server:

ssh -p 12345 otthoni_felhasznalo@localhost

Be sure to enter the home_username on your home computer, followed by its password, not the proxy server.

What happens here is that you connect to the proxy server with the SSH command (localhost), but since you are logging in to the redirected port, the proxy server already redirects it to the computer at the other end of the open SSH tunnel. and the SSH protocol of the home computer. And since we entered the username of the home computer, it also logs in to SSH with it, and then asks for the password, because the public key is not set backwards.

The first time you log in, you will be asked the first time you ask for your password, which you should answer yes to:

The authenticity of host '[localhost]:12345 ([::1]:12345)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:42:e8:13:55:0b:96:ce:f7:fe:87:e9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:12345' (ECDSA) to the list of known hosts.

The home computer is then stored on the proxy server as a known host. Then enter the password for the home computer user and you are already on the home computer.

Connect to a NAT-hosted machine directly through the SSH tunnel

Everything works so far, but it’s not perfect yet because we have to log in twice to access the home computer. We need to log in to the proxy server once and then to the home computer from there. This is so a little uncomfortable.

Fortunately, there is a solution to this as well, so that you only have to log in once to access your home computer. To do this, we need to configure sshd on the proxy server to allow port forwarding not only from localhost but also from external addresses.

On the proxy server, open the / Etc / ssh / sshd_config file:

sudo nano /etc/ssh/sshd_config

And add the following line:

GatewayPorts clientspecified

Then restart the ssh daemon:

sudo service sshd restart

Then close the duct as described above at either end of the tunnel and reopen a new SSH tunnel on your home computer, but in a slightly different way:

ssh -fN -R 100.100.100.100:12345:localhost:22 kozvetito_felhasznalo@100.100.100.100

 

 

(we can also insert the unique port here if we do not use the 22 port on the proxy server)

Here, the difference from opening the SSH tunnel above is that we also specified the public IP address of the proxy server, so the endpoint of the channel is no longer the 127.0.0.1:12345 (since we didn't specify it earlier, so localhost is the default), but 100.100.100.100: 12345, the public IP address of the proxy server, which means that the other end of the channel can be accessed directly from the outside world without the need to log on to the mediation server.

Once the channel has been opened, we can check the success of the redirect here by using the command on the proxy server:

sudo netstat -nap | grep 12345
tcp    0   0 100.100.100.100:12345    0.0.0.0:*     LISTEN      23060/sshd: kozvetito_felhasznalo

Now you can connect to your home computer from anywhere with a single login. So on the client computer, type the following command:

ssh -p 12345 otthoni_felhasznalo@100.100.100.100

So enter the username of the home computer and connect to the proxy server with the appropriate port number. Then the proxy server automatically forwards the traffic and we immediately find ourselves on the home computer.

Of course, we could have started with this localhost solution in the beginning, but it's worth keeping in mind that port forwarding made available to the outside world in this way is less secure than the "two-step" login above. Because this way one more port is already open, which can be seen when scanning one port. Of course, the SSH connection is secure, just worth mentioning as a security risk that otherwise applies to all open ports.

 

Setting up a durable SSH tunnel

There is only one thing missing for perfect operation, namely stability. The above works fine as long as there is no network outage or the service provider is thinking and changing the IP address, etc. Because in such cases, the SSH connection is lost, and so much to the tunnel, we can no longer access our machine remotely. And so we can't base such a relationship, which is quite vulnerable.

The autossh command, which automatically reconnects to rebuild our SSH tunnel after a network tangle.

Install the program on your home computer as follows apt-get command:

sudo apt-get install autossh

What is already mentioned above is absolutely necessary here set up SSH access without a passwordbecause without it you will not be able to reconnect in our absence.

If your previous channel is open, close it and open a new one with autossh instead.

autossh \
    -M 10900 \
    -o "PubkeyAuthentication=yes" \
    -o "StrictHostKeyChecking=false" \
    -o "PasswordAuthentication=no" \
    -o "ServerAliveInterval 60" \
    -o "ServerAliveCountMax 3" \
    -fN \
    -R 100.100.100.100:12345:localhost:22 kozvetito_felhasznalo@100.100.100.100

Because of the length of the command, I split it into several lines to make it clearer.

The meaning of the parameters is as follows:

  • -M 10900: Monitor port. This is used by the autossh program to send test data, which monitors the status of the connection.
  • -o "PubkeyAuthentication = yes": Use Public Key Authentication instead of Password (this is why you need to set it up)
  • -o "StrictHostKeyChecking = false": Skip skip unknown host.
  • -o "PasswordAuthentication = no": This is associated with the public key option: disables the password prompt
  • -o "ServerAliveInterval 60": Sends a vital sign every 60 seconds
  • -o ServerAliveCountMax 3: Sends maximum number of life signals without any response. It then disconnects and reconnects.
  • -fn: It puts itself in the background, just as it does with ssh, and does not execute a command.
  • R ...: These are the tunneling settings you have used before

(Here, too, we can append the unique SSH port number with the -p parameter if we are not using 22 on the proxy server)

This command creates a stable SSH tunnel, which will automatically reconnect in the event of a power failure.

Here's how to disconnect this channel from your home computer:

killall autossh

(of course, if we don't use other autossh instances, because then the PID will be retrieved and fired)

Alternatively, if you want to boot after restarting your machine, put the autossh command in a shell script, make it executable, and set it to boot automatically.

 

 

Conclusion

So with this method, we can make our home or work computer accessible from anywhere, wherever we are. By building an SSH tunnel, the connection can be used for many things, not just to run terminal commands. It can be used for SFTP file management, or file synchronization with rsync, or anything that works over an SSH connection. For example, I set up my home machine in the SSH file transfer section in the X-Plore file manager on my mobile phone, so I can conveniently access my home stuff from anywhere.

Of course, I also use a remote control program (TeamViewer), but as I wrote at the beginning, this is not always the most practical choice. For example, the file transfer part is far from as convenient as the X-Plore file manager. Anyway, perfect for remote table handling.

 

 

Hozzászólások

Similar to IPSec and VPN, which allows the VPN set up on the router to cover the entire network, is it possible to add access to our internal network as if we were at home? 

 

How do I configure the SSH tunnel to say 192.168.1.0/24? Yes my machine is not a router so just a host on my internal network. Now I don't know if this can be solved, let's say if you can't reach the Natol network from a Public address in this way.

This method requires a public fixed IP address. If this is available, you can redirect different ports to access machines on your internal network through a server available at the public address. And if a machine is already available within the network, other machines can be accessed in the same way. But if you want to access an entire internal network directly, you need to set up a VPN. This description does not cover this.