The first ten minutes on a new machine

A rented box is on the public internet within seconds

The moment a provider hands you an IP address, strangers start knocking. Put a fresh machine online with password login enabled and you will see failed SSH attempts within minutes: usually thousands a day, from botnets working through root, admin, ubuntu, postgres and every password in a leaked list. None of this is personal. It is a script.

So the first ten minutes on a new machine are the same ten minutes every time, and they are worth turning into a checklist you keep.

Keys, not passwords

Generate a key pair on your own machine, not on the server:

ssh-keygen -t ed25519 -C "laptop-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.10

Ed25519 keys are short, fast, and the current default. RSA still works if you use 4096 bits, and you will meet it on older systems.

The private key never leaves your laptop. What you copy to the server is the .pub half, which lands in ~/.ssh/authorized_keys. Anyone who can write to that file can add their own key and let themselves in, which is why the permissions matter: 700 on ~/.ssh, 600 on the file. With the default StrictModes setting, sshd ignores authorized_keys if it, ~/.ssh or your home directory is writable by anyone but you, and gives the reason only in the server’s log.

Put a passphrase on the private key. Without one, a stolen laptop is a stolen server. ssh-agent means you type it once per session rather than once per connection.

Turn off what you are no longer using

In /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

Then sudo systemctl reload ssh. Keep your current session open while you test the new one in a second terminal. Locking yourself out of a machine you have no console access to is a real way to lose a weekend, and it is entirely avoided by not closing the first window.

Changing the SSH port from 22 is popular advice. It removes most of the log noise and stops none of the serious scanning, which enumerates ports anyway. Treat it as tidying, not security.

Do not work as root

Create a normal user, give it sudo, and use it. Root has no undo and no audit trail: every process it starts, every file it writes, every rm -rf with a typo in it runs with the whole machine’s authority. The habit costs nothing and it is the difference between a mistake and an outage.

Your application should run as its own user too, one with no login shell and no write access to its own code directory. If the process is ever made to run attacker-supplied code, that user’s permissions are the blast radius.

Close the ports you are not using

Everything a fresh install starts (a database on 5432, Redis on 6379, an admin panel on 8080) is reachable from the internet unless something stops it. Databases exposed this way are found and emptied within hours, and there are search engines dedicated to listing them.

sudo ufw default deny incoming
sudo ufw allow 22,80,443/tcp
sudo ufw enable
ss -tlnp    # what is actually listening, and on which address

Read the ss output carefully. 0.0.0.0:5432 means the whole internet; 127.0.0.1:5432 means only this machine. A cloud provider’s security group does the same job one layer out, and it is fine to have both.

Patches, applied by something other than your memory

On Debian or Ubuntu:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

This installs security updates on its own. It will occasionally need a reboot to take effect, which is what /var/run/reboot-required is telling you. Unattended upgrades are the highest-value five minutes on this list, because the alternative is a machine that stays on a kernel with a public exploit until you happen to think about it.

Two habits that save you later

• Write the machine down. One file in your repository: what it is, who pays for it, what runs on it, which DNS names point at it. A server nobody can name is a server nobody dares turn off.
• Assume it is disposable. If rebuilding this box from nothing would take you more than an hour of remembering, the recipe should be in a script, not in your head. That is the whole argument for configuration management, and a shell script committed to the repository already counts.

The free path

All of this is OpenSSH, ufw and systemd, which ship with every Linux distribution and cost nothing. mosh is worth installing if your connection drops on trains. Managed platforms hide this entire lesson from you, which is a genuine advantage, until the day you need to know what a machine is doing, and the machinery underneath is the same either way.