Before complicating the setup even more (by adding more software), I'd opt to make sure I configure the software I already have before going down that route. Removing password login + changing the port would already remove any attack surface and make most scans not finding it at all. And if I'd still be annoyed by the amount of log items at that point, I'd add MAC/IP filtering at the firewall level before getting to the point of adding something like Tailscale.

Unless I had multiple users who'd need to login of course, but then Tailscale suddenly become a paid product, and I'd probably add another instance as a bastion host at that point.

I guess my point is: Make sure the software you already have is configured the right way before adding more software on top.

I’d say MAC/IP filtering is more annoying in the long term than Wireguard, since I’m not sure I could say that I will 100% never need to access the server unexpectedly from somewhere else.

But the ordering before that seem very reasonable. Although Wireguard is a soft alternative to changing default port, so it might be worth doing that.

On a slight tangent, I’ve never really bought into changing SSH port from default. I’d say the convenience of not having config/extra port specification is worth having it on a well known port, but that’s just my personal philosophy. I feel like for my low traffic things, just having strong SSH key and auto-updates is good enough.

Changing the port cut the invalid auths from 1000s a day to 0. Why deal with and log that spam?

Depends, I don’t think the storage requirements for the spam is that high and I would rather just use grep than remember the nonstandard port I picked.

But I guess this is partly because I tend to look at logs a lot less than I SSH into my server.

> I guess my point is: Make sure the software you already have is configured the right way before adding more software on top.

Couldn't agree more!

No need for any kind of MAC filtering: MAC is not propagated outside the L2 broadcast domain, so your server will see only the MAC of the default gateway (the router).

What exactly are you trying to accomplish with MAC filtering?

Have you not heard of the immensely popular man-between-the-first-hop-attack where hackers physically attach another hop between your server and its gateway?

Even in that joke scenario it doesn't make sense, since those attackers control the MAC layer already.

No, I've only encountered (wo)man-unplugging-the-first-hop. It leads to a lot of dropped packets and impacts all connected peers of the first hop.

I'm guessing to auth client devices (i.e this is my laptops Mac address, allow this)

Not sure I understand the point of Tailscale. The server should expose these ports to the internet...that's part of its purpose. Admittedly, I have never heard about Tailscale until now; it appears to solve a different kind of problem than the one I am interested in.

You don’t add tailscale if you care about open source.

You can run your own self-hosted Tailscale control server with Headscale.