The first ten minutes on a new VPS

A new server is at its most exposed in the minutes after it boots. Automated scanners find a fresh IPv4 address within seconds of it going live, and the default configuration of most distributions is built for convenience, not for a public network. The checklist below takes about ten minutes and removes the overwhelming majority of that risk.

1. Create a working user and stop using root

Log in with the root credentials we email you, create an unprivileged user, give it sudo rights and copy your public key across. From that point on, root logs in only through the serial console.

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

2. Turn off password authentication

Key-based authentication is not optional on a public server. In /etc/ssh/sshd_config set PasswordAuthentication to no, PermitRootLogin to prohibit-password, and reload the daemon. Keep your current session open while you test the new one from a second terminal — locking yourself out is the classic mistake here.

3. Close everything you are not using

Start from a default-deny firewall and open only what the machine actually serves. On Debian and Ubuntu, ufw is enough for most people.

ufw default deny incoming
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

4. Enable unattended security updates

Security patches applied three weeks late are the second most common cause of compromise we see, after weak SSH configuration. Install unattended-upgrades and let it apply security packages automatically; schedule reboots for a window you can live with.

5. Take a snapshot before you deploy

Snapshots are free on every Klarcloud plan. Take one once the base configuration is done and before your first deployment, so a bad install is a two-minute rollback rather than an evening of reconstruction.

What we handle for you

• Volumetric DDoS filtering at the network edge, on by default.
• Out-of-band console access so a broken firewall rule is recoverable.
• Rescue mode with your disk mounted, for the times fsck is the answer.

Everything above the hypervisor is yours. That is the trade-off of a root server, and the ten minutes are worth it.