Security

SSH Key Hygiene on Cloud Servers

Keys accumulate silently and rarely get removed. A few habits keep access accurate over the life of an environment.

SSH keys are the main way people reach cloud servers, and they have an awkward property: adding one is trivial, and nothing ever reminds you to remove it.

How keys accumulate

A key is added to bring a contractor on board. Another is added so a deployment script can connect. Someone copies the authorised keys file to a new server as a convenience. Two years later the file grants access to people who left long ago and nobody can say which key belongs to whom.

Habits that prevent this

One key per person, per purpose

Shared keys destroy accountability. If three people use one key, a log entry identifies the key, not the person. Individual keys mean removing one person’s access is a single line.

Always use a passphrase

An unprotected private key on a stolen laptop is immediate access to every server that trusts it. A passphrase plus an agent means you type it once per session and the key is useless on its own.

Comment every key

The comment field at the end of a public key is free-form. Put the person and the machine in it. An authorised keys file with meaningful comments can be audited; one full of anonymous entries cannot.

Separate deployment keys

Automation should have its own key, restricted where possible to the specific command it needs. Never reuse a person’s key for a pipeline.

Auditing

Periodically, and always after a handover, read the authorised keys file on every server and confirm every entry. Anything unexplained should be removed. Most providers also keep an account-level key list used when creating machines; clear that too, or removed keys reappear on the next server you build.

Reducing the problem

The best long-term reduction is needing fewer keys. Where a provider offers browser-based or agent-based console access for occasional administration, fewer standing keys need to exist at all. Where infrastructure is rebuilt from images, keys are provisioned at build time rather than accumulated by hand.

Key management sits alongside the wider baseline in a practical security baseline for a new cloud server.

Cloud accounts on OldCloudShop

Ten providers, every configuration and the starting price for each.

Browse cloud accounts Back to the library

Question about a listing? Message us on Telegram or WhatsApp.

Telegram WhatsApp

Continue in the library

Other entries covering account structure, billing, security and provider infrastructure.

FundamentalsHow to Size Your First Cloud ServerStart smaller than feels comfortable, measure the right things, and resize once you have evidence. A practical method that avoids both extremes.Cost controlWhy Cloud Bills Surprise People: The Usual SuspectsUnexpected invoices are rarely caused by the servers you deliberately launched. Here are the line items that actually cause the surprise.AccessRecovery Options: The Access Path People ForgetRecovery email, phone numbers and codes are a second key to the account. Leaving them unchanged undoes every other security step.CreditsHow Cloud Credits Are Applied, and What They Never CoverCredit is not cash. It applies to eligible services, expires on a date, and is consumed silently. Those three properties explain most credit surprises.ComparisonAWS and Google Cloud: How the Two Models DifferBoth run enormous infrastructure. They differ in how accounts are structured, how permissions are expressed and how the catalogue is organised.HandoverDocumenting a Cloud Account HandoverA short written record of what was received and what changed turns a vague inheritance into something a team can operate and audit.