How to access Linux Machine sitting behind a NAT, having no GUI?

Question

One of my Debian Boxes has no GUI. How to connect to it via command line from outside (like AnyDesk, Teamviewer etc...)?

I can use SCP & SSH to access this machine while I am inside office network. But how I can access from my home? Dynamic DNS (DDNS or DynDNS) is not applicable in my setup since the network provider is not assigning a Public IP to the WAN port of the router

Answer 1

Update: If the hourly connection check doesn't work for you (as in an hour is too long to wait for it to re-connect), take a look at autossh. The whole script on the debian server would be replaced with a proper autossh command in cron's @reboot or similar fashion.

---

Reverse SSH is your friend. You need an SSH server for this to work. I will give you two approaches for this, the first assumes you can open and run an SSH server from your machine at home. I will provide a way that tries to re-connect automatically hourly so your PC at home doesn't have to be always online. Since this can be either impossible or difficult sometimes, I will add an easier and safer solution too, which requires you to have a linux VPS though. They are usually just $2/month-ish.

Solution 1 - Using just your PC at home - Assuming static IP:

Preparation on the debian server:

I'm assuming you have cron installed and running. Create a new file in /etc/cron.hourly with the following content: (don't forget to chmod +x the file!)

#!/bin/bash
cstate=$(netstat -na | grep "tcp" | grep "<IP-of-home-machine>:22" | tr -s " " | cut -d " " -f 6 | head -n 1)
cdate=$(date "+%Y-%m-%d %H:%M:%S")
if [[ $cstate == "ESTABLISHED" ]] || [[ $cstate == "TIME_WAIT" ]]
then
    echo "[$cdate] SSH connection up. ($cstate)" >> /var/log/check-ssh-relay.log
else
    echo "[$cdate] SSH connection broken. ($cstate) Reconnecting..." >> /var/log/check-ssh-relay.log
    ssh -N -f -R 12122:localhost:22 <username>@<IP-of-home-machine>
fi

This will check hourly if the connection is up and tries to re-connect if it isn't. Useful when your PC at home isn't always on. It writes log information to /var/log/check-ssh-relay.log. Authentification is done via SSH-keys so make sure you got that setup properly in advance.

On your computer at home:

Assuming you have openssh-server setup properly, all you need to do now is:

$ ssh <server-username>@localhost -p 12122

To create the SSH connection. SCP, SFTP and co. works too of course.

Solution 2 - Using another VPS as relay:

I use this solution personally. Mostly because I do not have a static IP at home.

Preparation on the debian server:

Exactly like in solution 1, except for instead of <IP-of-home-machine> you use the VPS' IP here.

Preparation on the VPS:

All you need to do here is run the following command as root user:

$ ssh -g -f -N -L 0.0.0.0:13122:localhost:12122 root@localhost

The -g is important here to allow global inbound connections for this port-forward.

On your PC at home (or literally anywhere):

Simply connect to your VPS now using the port 13122 (as specified above):

$ ssh <username>@<VPS-IP> -p 13122

Answer 2

If you don't have a GUI, all you need is a remote console - this is typically achieved with ssh which combines very good security with value added services like scp (remote file copy).

Answer 3

Your problem is likely that you are sitting behind a NAT that you do not control, and so cannot set-up port forwarding.

The easiest solution to this is reverse tunnelling - you set up a ssh connection from the machine you want to control, to the machine you want to control it from (This machine needs to be accessible via ssh)

see https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work

Answer 4

You could setup a OpenVPN server in your office (assuming you can forward the port out of your network onto the public WAN), have your non-GUI box connect to it (Like Baldrickk's answer; reverse tunneling), and then your server should be able to SSH into the non-GUI box, along with any other services running on that box.

I see a few problems with an approach like this, one of which is if your non-GUI box's client times out a connection will be impossible without SSHing into it locally (on the same network) and restarting the client.