Nowadays, there is a growing need 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 in free versions, where you can easily manage the desktop of the remote machine you have set up, or even synchronize files with them. It's all nice and good, but they all have the same problem: we can only use what they were made for. Remote desktop connection, file transfer, or touchpad 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.
Simple port forwarding could still help, but if you want to access a machine behind a multi-embedded network (router, firewall, etc.) from the outside, port redirects can get in the way. But luckily there is a solution!
This setup is done on Linux, so first you need a home or work computer running Linux. There are also SSH tunneling programs for Windows, but this section is just about configuring Linux. However, if you want to access your Windows home computer from the outside, you should install a Cygwin system, which should be downgraded to the minimum possible level (SSH, SSHd, default) shell commands, etc.) to avoid consuming a lot of resources. After that, the rest of the description will work. Hereinafter referred to as this machine home computer.
Second, we will need a live SSH access that can be accessed from anywhere on the Internet. This can be a dedicated server in a server park or a leased server, or a monthly app. 1000 forints VPS servicewith root access. But you can even have a Linux computer with a friend connected to a fixed IP address, and you can get a sniff for SSH access. This server is known as SSH access mediation server.
And finally, you need a computer, or cell phone, tablet, etc., which can be anywhere on the Internet, the point is to be able to initiate an SSH connection, after all, that would be our goal to access your home computer from anywhere via SSH. That's what we call it 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. You can use SSH anywhere without any problems. Through this open SSH tunnel, 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 client computer we can connect to it. From here, only the mediation server you need to open a new connection back to home computer and then mediate traffic between the two machines.
By the way, VPN networks, as well as the above-mentioned remote file-synchronization programs, use their own servers as mediation servers. So now we are setting up our own network like VPN.
Set up a connection
When setting up a connection, we use several parameters that remain the same until the end of the description. Therefore, we define them here:
- The proxy server must have an IP address 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.
At the time of writing this, I make these settings with my desktop computer (home computer with NAT DIGI net + router), my own leased server (proxy server), and my (mobile computer) mobile phone (client computer), with my own parameters, to reach my home plane. This way, I can guarantee the functionality of things.
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 firstname.lastname@example.org
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 the 12345 port of the proxy server to the 22 port of the local machine (home computer). If you use a different SSH port on your home computer than the default 22 SSH, then of course use it. Also, make sure that the 12345 port of your choice here is not used by other programs because you will have to choose a different port.
- kozvetito_felhasznalo @ 100.100.100.100: This, of course, defines the connection to the proxy server for kozvetito_user.
If your proxy server uses a different SSH connection port other than the default 22 port (for greater security), -p switch:
ssh -fN -R 12345:localhost:22 email@example.com -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:
To end a connection from your home computer:
And if you want to unmount the SSH tunnel on the other side, from your home computer, you first need to look up the process ID of the SSH command running in the background:
ps -x | grep 12345:localhost
The -x option also provides background processes. Output something like this:
3191 ? Ss 0:00 ssh -fN -R 12345:localhost:22 <kozvetito_felhasznalo>@100.100.100.100
Then shoot the resulting PID:
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 the proxy server connects to itself using the SSH command (localhost), but since it logs on to the redirected port, it is already redirected by the proxy server to 22 on the other end of the open SSH tunnel, port, which is the SSH protocol on your home computer. And since we have entered the username of the home computer, it also logs in to SSH and then asks for the password because the public key is not set back.
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 of the home computer user and we 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 because we need to sign in twice to access your home computer. You need to log in once to the proxy server and then to your home computer. This makes it a little uncomfortable.
Fortunately, there is a way to do this so that you only have to log in once to access your home computer. To do this, you need to configure sshd on the proxy server to allow port redirection 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:
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 firstname.lastname@example.org
(we can also insert the unique port here if we do not use the 22 port on the proxy server)
The difference with opening the SSH tunnel above is that we also provided the public IP address of the proxy server, so the channel end 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 email@example.com
So enter your home computer username and connect to the proxy server with the correct port number. At this point, the proxy server automatically transmits traffic and immediately finds itself on the home computer.
Of course, we could have started from scratch instead of using the localhost solution, but it's worth remembering that port redirection made available to the outside world in this way is less secure than the "two-step" login above. Because one port is already open, which can be seen when scanning one port. Of course, the SSH connection is secure, but it's worth mentioning it as a security risk, which applies to any open port anyway.
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
You will definitely need to configure the SSH login without the password mentioned above, as 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 firstname.lastname@example.org
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 comes with the public key option: disables password reset
- -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:
(of course, if you do not use other autossh instances, this will keep searching for the PID and firing it)
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.
This way, you can access your home or work computer wherever you are. By building the SSH tunnel, you can use the connection for much more than just running 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, in the X-Plore file manager on my mobile phone, I set up my home computer in the SSH file transfer section, so I can easily access my home stuff from anywhere.
Of course, I 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 not nearly as convenient as the X-Plore file manager. Otherwise perfect for remote desktop management.