How to securely access an SSH server without a static IP address?

Hello everyone,
I hope this is an alright spot to post this.
However, I recently set up a home server machine and I cannot seem to figure out how to properly utilize the SSH server without a static IP.

Does anyone have any utilitarian solutions to this problem?
Thank you so much in advanced.

2 Likes

Dynamic DNS.

3 Likes

Automated hourly script to update pointers:

Would be helpful to know how often the IP address actually changes.

There are two problems here:

  1. How to be secure?
  2. How to find the server in the first place?

The first reply somewhat addresses the second question.

The first question would involve being very careful to cache and check the fingerprint on any client computer.

Given your setup, you may also have to contend with NAT.

1 Like

My recommendation is setting up a wireguard VPN in your local network, expose that through NAT via non-default port, setup dynamic DNS to access the VPN and once connected you can securely SSH into your server. I still recommend using SSH via public key authentication only though, just to be safe.

2 Likes

This is the way:

  • do not expose SSH to your public IP, only allow it over the local network + Wireguard network
  • use Wireguard (OK to expose port on public IP) + DynamicDNS
3 Likes

This is a wonderful solution.

I had seen this elsewhere and assumed with full certainty that DynamicDNS providers must weaken the security of your personal machine.

However, after additional research I recognize this may not be a fully valid conclusion.

Thank you so much for your response and help!

—Best

1 Like

They probably do in a sense. You are opening up additional points of attack, and dependencies on another party whom you will find it difficult to audit. At the end of the day though, if you are using strong, appropriate end-to-end encryption then even if the DynamicDNS provider is compromised or can’t be trusted, you will detect that.

I solve the problem of the dodgy DynamicDNS provider by being my own DynamicDNS provider. :slight_smile:

1 Like

In so far as in theory they could be compromised and redirect you to a different server in a similar hypothetical to a regular DNS provider, sure. And I guess in theory whatever application you use on your system to check in to the DDNS provider could be compromised like any installed application, so more applications does mean a larger risk. Beyond that, not really. It’s my opinion that those two areas of increased risk are relatively small and relatively minimal effort to mitigate.

SSH by default will inform you that something about the server has changed if the provider were to try and redirect you to a malicious server, and you can add-on security layers from there as you see fit.

Application security is its own security risk that should be being addressed for all your applications to begin with, so nothing unique to DDNS here.

I’m intrigued as to how that would work?

2 Likes

Yes, I wondered whether anyone would query that. :slight_smile:

I admit that my configuration is perhaps unusual but … I have a VPS, which has a static IP address. The VPS is a DNS server for a number of domain names. My home internet connection does not have a static IP address.

However I want to make my home internet connection accessible under a fixed fully qualified domain name (same as the OP).

My home router supports “dynamic DNS” and I have enabled that functionality (and the router has a pulldown menu for which specific Dynamic DNS provider is to be used). So every time my home internet connection changes WAN IP address, the router will attempt to use dynamic DNS to update. The penultimate piece of the puzzle is that for any given Dynamic DNS provider my home router will hard-code a host name that it will contact to make the update. The final piece of the puzzle is that I run my own local DNS server at home and my router will use that DNS server to resolve the host name - so my local DNS server can poison that host name - so that instead of the update going to the real Dynamic DNS provider, the update goes to my VPS.

The rest is just what happens on the VPS to do something to convert the dynamic DNS update into something that actually reflects in the DNS.

3 Likes

is a beautiful service, for what it’s worth.

2 Likes

1984 offers it for gratis:

I personally use 1984 and highly recommend their FreeDNS servers for ease of use.

1 Like

There are heaps of Dynamic DNS service providers available. The constraint is typically though that your router has to support that provider i.e. be able to be configured to communicate with the provider and be cognizant of the protocol used. (I don’t know whether all providers have coalesced around one de facto protocol standard or some have gone off in their own direction.)

… assuming of course that you are using a COTS router.

1 Like

There are a few COTS routers that allow extensive (command line and editor) configuration.

2 Likes

afraid.org just uses a cron script to ping their service and identify your machine’s IP, then it automatically updates the DNS records, no special protocol needed.

3 Likes

Interesting approach.

Doing it in the router may be more responsive i.e. the router knows when the WAN IP changes and directly triggers the dynamic DNS protocol. I guess if the cron job runs every few minutes, you wouldn’t notice the difference.

My scenario is dual WAN and I’m not sure that a cron job would give the right behaviour in my very particular scenario because the hostname should resolve dynamically to the WAN IP address of the specific interface. So in principle I could be operating dynamic DNS independently on each WAN interface. The router can just tell my VPS each time any interface changes WAN IP address (and telling the VPS which interface it was). The router is actually triple WAN but I’m only using 2 WANs at the moment.

I can see that many people would instead want a hostname that resolves in a combined way to whatever WAN interface is working, with a preference for the faster interface. Some people might even want both behaviours together (so three hostnames, one that always resolves to one interface, one that always resolves to the other interface, and one that resolves to whatever is working).

2 Likes