Learn
Security inventory — 7 checks people running several servers overlook
For solo and small-scale operators, incidents come less from missing controls than from untracked state. A 7-point security inventory: audit the key-holding PC, tier 2FA, matrix your SSH keys, and remove plaintext passwords — risks you can delete just by listing them, explained defensively.
For solo or small-scale operators who manage several servers, sites, and domains. The more you've postponed taking stock because "it works," the more this applies. No attack steps here — only risks you can list and delete yourself.
"Count and cut" before "add"
Untracked state is itself a risk. Take stock and you usually find:
1. Defend the "PC with the keys," not the "server"
No matter how hard you harden the server, if the PC holding your SSH private key is compromised, everything opens. Once you switch to key auth, the real boundary of your fleet moves to "the PC that holds the key." So the priority isn't "server → PC" but "PC → server."
The highest-value check: whether .ssh sits OUTSIDE a cloud-sync folder (OneDrive/Drive/Dropbox). If a private key accidentally lives under sync, your key leaks the moment the cloud account falls — even without touching the PC. The least-privilege mindset for keys is in SSH keys and least privilege.
2. Tier 2FA by the "root of trust"
"Add 2FA to everything" never ends if you start vaguely. Tier it by the chain of control (root of trust) and the priority decides itself.
| Tier | Target | Why it's top priority |
|---|---|---|
| Tier 0 | Email account | Almost every service recovers via "reset link to email" — take the email and the lower 2FAs are bypassed |
| Tier 1 | Domain control (registrar/DNS/hosting/code platform) | The site itself can be hijacked or swapped |
| Tier 2 | Billing APIs (payments / AI APIs / mail sending) | Leads to direct financial loss |
The practical keys: keep backup codes on paper (putting them in the cloud halves the point of 2FA), and confirm your recovery email is alive and under your control. Steps are in the multi-factor authentication guide and the security baseline checklist.
3. SSH keys aren't "managed" until you matrix them
"It's key auth, so it's safe" is not management. What you actually need is one table of "which key on which PC opens which server." Match each server's authorized_keys by fingerprint and the invisible appears — duplicate keys (the same key under two names), unused keys (used nowhere), and orphan registrations (left over for a purpose that's gone). authorized_keys is easy to add to and easy to forget to prune. A matrix lets you ask, row by row, "what is this for?"
4. EOL devices: the least-effort cut, weighed by effort vs risk
A key on a device whose OS reached end of life (EOL) is common. Going big — "rotate every key and reconfigure every server" — is so heavy you never do it.
Check for any sign of leakage
The least-effort cut = delete the key from the device
Put the cliff on a calendar
The trick: pick the cut you can actually finish today over a perfect procedure you leave undone.
5. Remove plaintext passwords from the cloud
Before the password-manager debate, there's a bigger real harm: a plaintext password list sitting in a cloud document. Leak it and it's instant total loss.
Plaintext list (a cloud document)
- One account falling leaks everything
- You'll paste into a fake site by hand
- No breach detection, no autofill
On-device-encrypted storage
- Contents are encrypted on your device (provider can't read them)
- Won't autofill on a fake domain = phishing-resistant
- After migrating, delete the plaintext for good
"Which manager is best" matters far less than "did you remove the plaintext from the cloud" (→ how to choose a password manager / storing passwords safely).
6. Remediate "reversibly, one at a time"
When the inventory surfaces problems, you'll want to fix them all at once. In production, changing several things on momentum is the most dangerous move. Hard-to-undo operations — key rotation, config changes, production deploys — should be done one at a time, after preparing a full backup and a restore procedure (i.e. make it reversible). Don't open a new hole with the remediation itself (→ backup and recovery).
7. Design the ledger to hold no secrets
The ledger of your results becomes an attack map if it leaks. So draw the line up front.
Fine to write (not catastrophic if leaked)
- Public keys, fingerprints
- The structure of your setup, whether 2FA is on
- Pass/fail results
Never write (one line weaponizes it)
- Private key contents
- Passwords, API keys
- Real reset codes
Fingerprints and public keys only identify "which key" and can't be abused alone. Express your state using only information that isn't catastrophic if leaked — then the ledger stays safe in the cloud or shared with a team.
This site's view: inventory before addition
On this site we never keep secrets (keys, passwords, connection details) in plaintext — not in shared docs, not in code — we split keys per purpose (one leak doesn't cascade = minimal blast radius), and we remediate reversibly, one at a time. Before adding a new tool, first turn "untracked state" into "a listed state." It's unglamorous, yet it deletes more risk than anything else.
Read next
- Keys: SSH keys and least privilege
- Baseline: Security baseline checklist · Multi-factor authentication guide
- Storage: How to choose a password manager
FAQ
QWhat is a security inventory?
Before 'adding' new controls, you list the keys, accounts, devices, and registrations you already have, find the unnecessary or dangerous ones, and reduce them. For solo/small operators, incidents come less from a missing firewall or WAF than from untracked state — 'which key on which PC opens which server?', 'is 2FA on or not?' An inventory deletes that.
QWhere do I start?
The order is PC → server. Once you use key-based SSH, the real boundary moves from the server to the PC that holds the key. First audit the health of the key-holding PC (especially whether .ssh sits OUTSIDE a cloud-sync folder), then your email account's 2FA and backup codes, then the SSH-key inventory.
QIs a ledger of the results safe to keep?
It is if you draw the line on content. Public keys, fingerprints, the structure of your setup, whether 2FA is on, and pass/fail results are fine to write (none are secret). But never write the contents of a private key, a password, an API key, or a real reset code — not even one line. Express your state using only information that isn't catastrophic if leaked, and the ledger never becomes an attack map.