How to secure your new VPS: a step-by-step guide

You should always verify that SSH password auth is actually off; run

  ssh -v myserver : 2>&1 | grep continue

and ensure that it only gives "publickey"!

(A surprising number of VPSs will re-enable passwords in a .d config file. And really, even if you've checked for that, the extra 10 seconds to make sure is worth it.)

opinions on the suggested fail2ban and ufw?

Good advice. Another option:

  ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no myserver

ufw yes, fail2ban doesn't necessarily do much for you if you have disabled password authentication.

fail2ban is a critical piece of security software, as is some firewall. for those new to linux, you might as well use the one that is super-easy to install.

This guide walks you through disabling password authentication for SSH, then walks you through setting up fail2ban.

The opposite is true about fail2ban: it's cargo-cult security, and people shouldn't be running it. It never made any sense, but it especially makes no sense if you're going to (sensibly) disable password authentication.

Always remember though (and, before anyone says this is obvious, I once shocked an HN reader who hadn’t thought this through):

All of your VPS security is meaningless compared to your VPS provider’s security, the security imposed on the employees of the VPS provider, the security of your VPS account password, and their susceptibility to faked subpoenas and faked emergency data requests.

It’s insane to me that in 2024 it still takes this much back and forth to set up a server.

I even recently tried automating this but quickly realized I was falling into an XKCD trap because the process is so damn painful.

I would have appreciated the rationale behind setting 'UsePAM' to 'no'. I assume it's because, with password auth disabled, it's not necessary, and better to disable something that you don't need that would otherwise add to the attack surface?

Honestly, for somebody running a personal server, ufw/iptables/etc tend to not be relevant for any direct security. Basically nobody is doing anything for outbound rules other than ACCEPT, and for inbound... people can only connect to services you're running on your public interface. So for most people, they'd just be setting up ufw/iptables/etc to allow traffic to the set of services they're running (ssh, a web server, etc) anyways.

That said, I do think there's some value in understanding what your server is running and what it's exposing to the network, and setting up firewall rules is one of many ways to build familiarity with that.

fail2ban is just junk, and shouldn't be running on any modern system.

I recommend installing Tailscale, and using a firewall outside of the VPS like how Linode or EC2 does it. Don't even allow port 22 at all... Tailscale let's you access all your stuff without needing to expose ssh ports.

Far more VPSs are compromised through local VM attacks than provider attacks.

This is a bit like saying "When you're temping your chicken, always remember that your grocery store could be putting arsenic in it at the store". Yea, that's true. But the average consumer gets sick far more often from mistakes in the kitchen than mistakes in the grocery store.

The person in question on HN was planning to self-host email. Sure, if you don’t want Google or Microsoft in particular reading it, I get it. But if you think nobody can read it now, that’s a major (potentially life threatening) mistake. Gmail might actually be safer in many circumstances.

Most cloud providers will accept a cloud init cloud config file. Sometimes they call it a “script” but they still accept the Yaml file if it has the `#cloud-config`.

There are modules for setting up ssh, adding users, installing packages, etc.

https://cloudinit.readthedocs.io/en/latest/index.html

If you don’t want Google or Microsoft reading your email, Proton would be better still than Gmail, wouldn’t it?