SSH — passwords and permissions

The first server I ever put on the public internet was attacked within about twenty minutes. Not by anyone who knew it existed or cared what was on it — by an automated system that scans the entire internet continuously, finds anything answering on the port used for remote login, and starts guessing usernames and passwords. I found the log the next morning: thousands of attempts, alphabetical, tireless.

That log taught me more about security than any course I had taken. Not because of the attack — it failed — but because of what it revealed about my mental model. I had been thinking about security as a question of secrets. The log was asking a different question: not "what do you know?" but "who are you, and what are you permitted to do?"

Changing a password is a permissions lesson in disguise

Start with something that looks trivial. You are logged in to a server and you change your own password. It works, and nothing seems remarkable about it.

Now try to change somebody else's. The system refuses. Not because your password was wrong — you already proved who you are — but because that operation belongs to someone with more authority than you have. The refusal is the interesting part. The system is not checking what you know; it is checking what your account is permitted to do.

Those are two separate mechanisms, and conflating them is the single most common mistake I see in people new to servers. Proving who you are is authentication. Deciding what that identity may do is authorisation. A stolen password defeats the first one entirely and does absolutely nothing to the second. This is why the question "how strong is your password?" is far less interesting than "what can that account do once someone is inside it?"

Keys instead of passwords, and why

The standard advice for remote login is to stop using passwords and use a key pair instead. Here is what that actually means, without the cryptography.

You generate two matched files. One stays on your computer and never leaves it — that is the private key. The other you copy onto the server — the public key, and it is not a secret; you could publish it. When you connect, the server sets a small mathematical puzzle that can only be answered by whoever holds the private half. Your computer answers it. The private key itself never crosses the network.

The practical consequence is what matters: an attacker guessing at your login has nothing to guess. There is no password to get right. Those thousands of alphabetical attempts in my log become permanently pointless, and I switched off password login on that machine the same morning.

The honest cost: you now have a file you cannot lose. Lose the private key with no backup and no second way in, and you have locked yourself out of your own server as thoroughly as any attacker could have. Everyone who works this way has either made that mistake or is going to. Protect the key with a passphrase, keep a copy somewhere sane, and — the step people skip — keep one alternative route to the machine that does not depend on it.

The account that can only see one folder

Here is where this stops being theory and starts being a thing I do on every machine I set up.

On a server holding a household's files, there is a process that runs every night and copies data to a backup location. It needs to read the files. It does not need to do anything else. So it does not run as an administrator, and it does not run as the person who owns the files. It runs as its own account, which can read the folders it backs up and has no access to anything else on the machine.

Why bother? Because it changes what a bad day looks like. If that backup process is compromised — through a bug in it, a mistake in its configuration, anything — the attacker inherits exactly its permissions and nothing more. They can read the folders it could read. They cannot reach the photo library, cannot install anything, cannot alter the system, cannot use the machine to attack anyone else. The blast radius is bounded, in advance, by a decision that took twenty minutes.

This principle has a formal name and a very simple statement: give every account the minimum it needs to do its job, and nothing else. It is not a Linux idea — every serious system works this way — but on Linux it is visible and adjustable, which means you can actually check whether you got it right.

What I actually do, in order

Four things, on every machine, before it goes anywhere near a network it does not control.

• No remote login as the administrator account. Log in as an ordinary user, then elevate for the specific thing that needs it. This single change removes the target every automated scanner is aiming at.
• Keys instead of passwords, with password login switched off afterwards — not before, or you will lock yourself out, which I have done.
• Automatic blocking of addresses that fail repeatedly. Not because it stops a determined attacker, but because it removes the constant background noise and makes the log readable. A log you cannot read tells you nothing.
• A separate, restricted account for anything automated, as described above.

And one thing I do not do, which is worth stating because the advice is everywhere: I do not bother moving the login to an unusual port. It reduces the noise in the log, which is pleasant, and it protects against nothing. A scanner that checks every port finds it in seconds. Obscurity is a tidying habit, not a security measure, and confusing the two is how people end up feeling safe while being exposed.

The whole lesson compresses into one sentence that I wish somebody had told me before that first log. Security is not mainly about keeping people out. It is about deciding, in advance and in writing, what someone can reach if they get in. The first is a wall and walls eventually fail. The second is a set of rooms with locked doors, and it keeps working after the wall has failed.