Key-based authentication
Logging in to SSH with a cryptographic key pair instead of a password. It removes the most common brute-force target: there is no password to guess, only a private key that never has to leave the user's own machine.
Why keys are considered safer than passwords
A password can be guessed, reused across sites, or leaked in a breach elsewhere. A private key does not travel across services, cannot be brute forced in any practical amount of time at modern key lengths, and never has to be typed into a login prompt where it could be intercepted or logged.
What actually has to go right
Key-based authentication only protects a server if the private key itself is protected: passphrase-encrypted, stored outside of shared or backed-up locations that other people can read, and removed from authorized_keys immediately when someone leaves a team or a laptop is lost.
Frequently asked questions
Should I still keep a password login as a backup?
No. Keeping password login enabled defeats the purpose, since it gives attackers a second, weaker path in even after you have set up keys.
What happens if I lose my private key?
You lose access through that key, but the server is not compromised, since the key never leaves your machine. Generate a new key pair and add the new public key to authorized_keys through another access method.
Is a passphrase on the private key necessary?
Strongly recommended. Without a passphrase, anyone who copies the key file itself, from a stolen laptop or a misconfigured backup, can use it immediately.
Want to see where your own server stands?
Run the free, read-only server check, or open the Security Lab and watch the detect, contain, recover, verify loop in action.
Get your free server checkOpen the Security Lab