Securing a Fresh Linux Server: The Checklist That Actually Matters

Keys first, passwords never

The single biggest cause of small servers being taken over is a password that could be guessed or reused. Generate an SSH key pair on your own machine — `ssh-keygen -t ed25519` — and understand which half goes where: the private key never leaves your laptop, and only the public half (the file ending in `.pub`) is copied anywhere.

On Tiny-Puter you save that public key on the dashboard and it is installed inside your container, so the only thing that opens your server is the key that never left your machine. Nothing about the door is guessable, because there is no password to guess.

• Never paste a private key into a chat, an email, or a web form.
• Never reuse the password you use for email anywhere near a server.
• If a laptop is lost, replace the key that was on it — that is the whole recovery story.

Know what is actually reachable

On an ordinary VPS, every service you start is listening on a public address, and public addresses are scanned continuously by automated tools looking for anything familiar. That is not a personal attack; it is background noise on the internet, and it never stops.

This is the part the container model changes. Your Tiny-Puter container has no public IP at all — it sits on a private network and you reach it through the SSH door — so there is no port to find. That does not make the inside free of mistakes, so still run `ss -tulpn` and look at what is listening: stop the services you are not using, and never leave a service running with no authentication just because you believe nobody can reach it.

Patch on a schedule, not on a bad day

Almost every compromise you read about is a bug that was fixed months earlier. On Debian, `apt update && apt upgrade` gets you current, and enabling unattended security upgrades means you stay that way without remembering. On Alpine, it is `apk upgrade`, and the base is so small that upgrades finish quickly.

Half an hour once a month is enough for a small server, but the safe habit is automatic security patches plus a quick look at what changed.

Read the log — someone is already trying

Failed SSH logins are normal. Every reachable Linux port on the internet receives constant automated attempts with usernames like `root` and `admin`, and seeing them in your log is not evidence that you have been breached — it is evidence that the internet works the way it does.

What matters is what those attempts are *against*. If the door only accepts a key, thousands of wrong guesses achieve nothing. We log failed door connections and alert on sustained attempts, so a campaign against the door is visible on our side and does not depend on you watching a log file at 3 a.m.

Do not become the attacker

A server that gets taken over is rarely kept for its own sake: it is used to scan other machines, relay spam, or flood someone. That is what gets accounts suspended and hosts blocked — by us and by the network above us.

So keep the same standard for what leaves your container as for what gets in: no open mail relays or proxies, nothing that turns your box into an amplifier, and no handing root access to software you have not looked at. Our terms describe what we then have to do, and the honest summary is that abuse of the network ends the account.

The order of operations

If you only do six things on a new server, do these, in this order: generate a key pair on your laptop; put only the public half where the server can read it; connect and run `ss -tulpn` to see what is listening; turn on automatic security updates; keep the services you run updated and the ones you do not run switched off; and treat your private key like the only copy of something you cannot recover.

None of it is exotic. It is just done in an order that closes the easy doors before you start building something you would hate to lose.