14 SSH Key Management Best Practices Every Developer Should Know (2026)
Hiren Kalariya
0:00 / 0:00
14 SSH Key Management Best Practices Every Developer Should Know (2026)
18 просмотров · 10 дней назад
Hiren Kalariya
8 подписчиков
18 просмотров · 10 дней назад
Most SSH breaches come from bad key hygiene, not clever attacks — like the key belonging to a developer who left 8 months ago and still has production access. These are the 14 SSH key management best practices for 2026, grouped across the full lifecycle: generate, store, control access, maintain, and scale — with the exact commands.
📖 Full written guide + 90-day audit checklist: https://ctrlops.io/blog/ssh-key-manag...
⭐ If you do nothing else, do these 3: use Ed25519 keys, put a passphrase on every key, and give each person their own key so you can revoke access the day they leave.
The 14 practices:
GENERATE
1. Use Ed25519, not RSA — the best SSH key type in 2026 is Ed25519: faster, shorter, and more secure than RSA 2048, and Mozilla's OpenSSH guidelines rank it first. Only fall back to RSA 4096 for servers older than OpenSSH 6.5.
2. One key pair per machine / use case — so a stolen laptop exposes one machine's access, not your whole fleet.
3. Passphrase on every private key — a stolen key with a passphrase is useless; load it once a day with ssh-add.
4. Meaningful key comments (your name + machine) — so at revocation time you know exactly which line to delete.
STORE
5. Keep private keys local — never Dropbox, Google Drive, iCloud, or a Git repo. (Wiz found 65% of the top AI companies had leaked secrets on GitHub.) Back up to an encrypted drive or a password manager.
6. Copy keys correctly — use ssh-copy-id, which sets everything up in one command.
7. Correct file permissions — 600 on your private key, 700 on the ~/.ssh folder, and 600 on authorized_keys. That "Permission denied (publickey)" error is almost always this.
ACCESS
8. Per-user keys, never a shared team key — removing someone becomes deleting one line instead of rotating for everyone.
9. Revoke the same day someone leaves — on every server they could reach. (A 2023 insider-risk report found 12% take sensitive data when they go.)
MAINTAIN
10. Audit every 90 days — and after any team or project change. On each server, list authorized keys and remove any you can't name.
11. Separate passphrase-free keys for CI/CD — locked to specific commands and rotated every 90 days. Never strip the passphrase off your main key.
12. Diagnose key errors faster — describe a cryptic error to an AI terminal that reads your server's state and suggests the fix (approval-gated).
SCALE
13. FIDO2 hardware keys for critical production — the private key is generated inside the device and never touches your disk.
14. SSH certificates past ~15–20 people — servers trust a central authority, developers get short-lived certificates that auto-expire, and there's no revocation step at all.
Where CtrlOps fits: every practice here can be done from the command line — the real question is whether you'll do it consistently at 11pm when someone just left. CtrlOps turns the steps people skip into one click: generate an Ed25519 key with a wizard, see every authorized key in a visual registry, revoke in one click, and diagnose errors with an approval-gated AI terminal — all local-first, nothing syncs to a cloud. Mac, Windows, Linux. $7/user/mo, one month free.
👉 https://ctrlops.io
⏱️ Chapters
0:00 The "ghost key" problem
0:19 If you do nothing else, do these 3
0:43 Practice 1: Ed25519, not RSA
1:19 Passphrases & meaningful comments
1:42 Keep private keys local, never cloud
2:09 Copy keys correctly + file permissions
2:36 One key per machine, per-user not shared
3:00 Revoke the day someone leaves
3:27 Audit every 90 days
3:48 Automation keys + AI diagnosis
4:11 FIDO2 hardware keys + SSH certificates
4:15 Doing it consistently
5:13 The 90-day audit checklist
5:34 Recap: start here
❓ FAQ
What's the best SSH key type in 2026? → Ed25519 — faster, shorter, and more secure than RSA 2048.
Ed25519 vs RSA — which should I use? → Ed25519, unless a server predates OpenSSH 6.5, in which case use RSA 4096.
What are the correct file permissions for SSH keys? → 600 on the private key, 700 on ~/.ssh, and 600 on authorized_keys.
How do I revoke an SSH key? → Delete that key's line from authorized_keys on every server the person could reach — the same day they leave.
How often should I rotate SSH keys? → Audit every 90 days and after any team or project change.
How do I manage SSH keys for multiple clients? → Use per-user keys with meaningful comments, and a visual registry so you can revoke per person.
Is it safe to store SSH keys in a password manager? → Yes — a password manager or encrypted drive is fine; cloud sync and Git repos are not.
🔗 Links
Full guide: https://ctrlops.io/blog/ssh-key-manag...
Website: https://ctrlops.io
If this helped you clean up ~/.ssh, like and subscribe for more.
#SSH #DevOps #Security #Linux #CtrlOps