0

I use Autossh run from a systemd service from a headless remote client. The remote client sets up a ssh tunnel back to my home firewall. My isp routinely changes my home ip. Therefore I use a dynamic DNS service (dDNS) so the remote client can find my firewall.

I have found that dDNS does not work from all parts of the world. If the remote client is located in a country where the dDNS service is blocked or not available, the remote client cannot find the ip address of my firewall.

As a backup I am modifying the client so my home firewall ip address can be manually entered by a user who has physical access to the remote client. This will require me to communicate the ip address by another channel (email, phone, txt etc). The user will manually enter the ip address via a web page interface served by the client. The user will never have access to the remote client cli.

When the user saves a manually entered ip address, it is stored in a home_ip.conf file in the user home dir (no need for root access). I have written a systemd path service that detects changes to the home_ip.conf file. A change to the home_ip.conf file means the user has entered and saved an ip address.

The alternative use case is that the ip address is deleted/disabled by the user and the client reverts to using the dDNS service.

At this point, I need to run a script that will close autossh (if running) and any related ssh tunnels (not all tunnels). Then restart autossh with a different ip/dDNS variable in the exec command line.

I have searched the internet and not found anything that exactly matches my use case. The closest I have got is this answer How to stop/kill an autossh tunnel? by @KeithMcFly. For my use cases, I don't think putting this script in .bashrc is the best option.

The command I use within the existing service looks like this:

Environment='AUTOSSH_GATETIME=0'
ExecStart=/usr/bin/autossh -M0 foo.ddns.org -F /home/fooUser/.ssh/fooUser_ssh_config -NR 9011:localhost:22 -NR 9012:localhost:8999

I am already using one Environment variable plus a ssh_config file (not the same as the home_ip.conf above) so one option is to replace foo.ddns.org with an environment variable or, I could change a value in the fooUser-ssh_config file.

Looks like I have a range of options to solve this problem. Which one would be considered "best practice" ??

user643684
  • 1
  • 1

1 Answers1

0

While not quite an answer to the headline I think the question is an XY question, so I'll answer with a possible solution to the problem that would also be a best practice.

Set up VPN infrastructure, and then connect to SSH across the VPN. This would be considered the best practice as it has numerous security and ease-of-use benefits. One of the advantasges is it hides your SSH server, and another is that the IP address becomes an internal IP address that does not change.

(Also, a hack which could be useful might be to get your home client to connect to a web server and have the web server log the IP address. You can then look at the web server to find the routers external IP even if Dynamic DNS is blocked. I must say though that I find the idea that dynamic DNS is blocked to be a bit odd. I do wonder if you could run your own authorative DNS servers backended by a database and build your own Dynamic DNS type system without triggering these firewalls. Its not that hard to do - PowerDNS can do this easily, no doubt among many nameservers)

davidgo
  • 68,623
  • 13
  • 106
  • 163
  • Thanks for your thoughts. I chose ssh because I need to be able to get through others firewalls. Specifically WAN telcos. The other factor is that connection is intermittent. I have the firewall configured to end the ssh connection in the firewall. Computers inside the Green network connect via end to end ssh tunnels out to the client. – user643684 Feb 18 '23 at 03:18
  • I will take a look at PowerDNS etc. – user643684 Feb 18 '23 at 03:20
  • I am scratching my head at the thought Telco would allow SSH but block VPN. An intermittent connection is all the more reason to use a VPN. (I've started an SSH session in one city, flown [without WIFI] to another city 2 hours away and the SSH connection continue to work because I was sshing over a UDP based VPN. I wonder if a VPN on port 443 UDP with a fallback to 443 tcp would would not be a better way through a firewall.... – davidgo Feb 18 '23 at 03:39
  • It's not that Telco's block SSH vs VPN. It is they stop incoming connections of any protocol. To make a connection the client needs to initiate the session out of the WAN to my home firewall. I have also found that some countries block vpn protocols and ports. I haven't had that problem (yet) with ssh. With autossh and ssh, I have been able to fine tune the connections to get through. Being able to allow a user to manually enter an ip address is the latest of a series of refinements. – user643684 Feb 18 '23 at 07:33