Shell access by key instead of by password

Shell access on a network of accounts is where password habits go wrong. One password gets reused across accounts because typing a different one each time is tedious, and once it is in a script or a shared note there is no way to know who holds it.

Keys remove the problem. Each key belongs to one machine or one person, the server holds only the public half, and access is withdrawn by deleting a single entry.

How the two halves work

A key pair is a private file that stays on your machine and a public file that goes on the server. Connecting proves you hold the private half without ever sending it. If the server is compromised, the attacker gets a list of public keys, which is of no use to them.

Making one takes a minute in the panel and the video above shows it. Two decisions inside that minute outlast the key itself: what you call it, which decides whether you can ever revoke it alone, and whether you set a passphrase, which decides what a stolen laptop is worth to whoever took it.

Then comes the step that catches almost everyone. A freshly made key is inert until you authorise it from its row. Skip that and the server declines it and quietly offers you a password prompt instead, which reads exactly like a broken key rather than an unfinished one.

Name keys so you can revoke one

This is the part that matters on an estate. A key named after the person or machine can be deleted the day a laptop is replaced or a contract ends, and nothing else is affected. A shared key named key1 can only be removed by cutting off everyone who has it, which means in practice it is never removed.

The same discipline applies to automation. Give the deployment runner its own key, not a copy of yours. When you rotate your own credentials, the deployment keeps working; when the runner is retired, its access disappears with it.

One key per account, or one key everywhere

Both are defensible and the choice is about blast radius:

• Same public key authorised on every account is convenient and means one compromised private key reaches the whole estate.
• A key per account is more setup and contains the damage to one account.

A reasonable middle position is one key for your own interactive work across accounts, and separate per account keys for anything automated.

When it does not connect

• A password prompt appears. Almost always the authorise step, not the key.
• Complaint about permissions. Your private file is world readable; tighten it to 600.
• Flat refusal. Shell is switched off for that account entirely.

If you use keys for deployment as well, they pair naturally with pushing a repository to the account, which uses the same authorised key rather than a second credential.