Kituwa IT · Field guide
SSH keys in plain English
SSH keys are a pair: a private key that stays on your device and a public key that you place on the server. The… Practical checks and official references.
SSH keys are a pair: a private key that stays on your device and a public key that you place on the server. The server challenges you; your private key proves you hold the matching secret.
This guide expands the Facebook post into a practical workflow for beginners, home-lab users, and small-business owners who want to understand the trade-offs before changing a working system.
What this guide covers
- SSH keys in plain English
- A pair, a passphrase, a policy.
- Key pair — Private + public
- Server — authorized_keys
- Fingerprint — Compare, don't paste
Why it matters
The goal is not to memorize a product name or copy a command blindly. It is to understand what the change affects, verify it against an official reference, test it on spare hardware or a virtual machine when possible, and keep a rollback path.
A practical walkthrough
Check ssh-keygen -t ed25519 -a 100
Use ssh-keygen -t ed25519 -a 100 for a modern key with a strong passphrase, or check your organization's approved algorithms. Generate a modern key, protect it with a passphrase, and copy only the public key. Use ssh-keygen -t ed25519 -a 100 for a modern key with a strong passphrase; check your organization's approved algorithms. Keep an offline backup of the private key if losing it would lock you out. Keep an offline backup of the private key if losing it would lock you out. Do not paste the private key into a chat, ticket, or website. A key without a passphrase is convenient and riskier.
Check authorized_keys
On the server, authorized_keys lists the public keys allowed to log in. Remove keys you no longer use. Fingerprints help you compare keys without copying the whole key.
Use the supported update path
Keys are not a complete access policy: use a non-root account, a firewall, and updates. Test a new key before disabling password login.
Your turn
Which key would you revoke first?
What to verify
- Use the official documentation for the exact version you run.
- Test on a spare device or virtual machine before changing a working system.
- Keep a backup and a rollback path.
- Record what changed and how you verified it.
Common mistakes
- Exposing a service before authentication and updates are ready.
- Changing several network variables at once.
- Forgetting DNS, TTL, firewall, or rollback details.
Quick checklist
- ☐ A pair, a passphrase, a policy.
- ☐ Key pair — Private + public
- ☐ Server — authorized_keys
- ☐ Fingerprint — Compare, don't paste
FAQ
What is the first step?
SSH keys are a pair: a private key that stays on your device and a public key that you place on the server.
What should I avoid?
Exposing a service before authentication and updates are ready.
Where can I verify the current details?
Use the official references below; versions and interfaces change.
References
Related guides
Need help?
If you want a second opinion on the setup or the rollback plan, Kituwa can review it with you. Start with the checklist above; it makes the conversation more useful.