Quick Answer: What is an ssh key?
An SSH key is a cryptographic key pair, one private and one public, that proves who you are when you connect to a remote server over the Secure Shell protocol. Instead of typing a password, your computer uses the private key to sign a challenge, and the server checks that signature against the public key it already stores. You can generate a pair with a tool like ssh-keygen, protect it with a passphrase, and use it for logins, file transfers, and Git operations. It differs from a password because the secret never travels across the network, and it differs from a TLS certificate because SSH runs its own trust model rather than a browser-style authority chain. Before you commit, compare key type, passphrase protection, file permissions, backup method, and where the public key gets installed. (Public-key cryptography)
Why Bother With Keys When Passwords Exist?
Ever typed the same password into a dozen servers and wondered what happens if one of them leaks it? That is the problem SSH keys were built to solve. A password is a shared secret: both sides know it, and anyone who guesses or steals it becomes you. A key pair splits that secret in two. The public half is safe to paste anywhere, while the private half never leaves your machine.
The Secure Shell protocol itself is old, stable, and specified in public standards. The architecture document that defines how SSH negotiates encryption, integrity, and server authentication is RFC 4251, the SSH Protocol Architecture, and the piece that actually covers key-based login is RFC 4252, the SSH Authentication Protocol. If you have ever wondered why every Linux server, router, and code host speaks the same login language, those two documents are the reason. (SSH public key authentication overview)
The practical upshot: keys are the default way professionals log into servers, push code, and automate jobs. Passwords still exist as a fallback, but they are increasingly the thing you disable once keys work.
The Two Halves of a Key Pair
An SSH key pair is mathematically linked. Data signed with the private key can only be verified with the matching public key. That one-way relationship is the whole trick.
| Part | Where it lives | Can it be shared? | Job |
|---|---|---|---|
| Private key | Your machine, usually in ~/.ssh/ | Never | Signs the login challenge |
| Public key | Server’s authorized_keys file, code hosts, appliances | Freely | Verifies the signature |
When you connect, the server sends a random challenge. Your client signs it with the private key, and the server checks the result against your stored public key. The private key is never transmitted, so a network snoop sees nothing reusable. Compare that to a password, which crosses the wire (encrypted, but still present) and can be replayed if the encryption is ever broken or intercepted at the endpoint.
This is also why people talk about hardware tokens and authenticator apps in the same breath. A hardware security key stores the private half in tamper-resistant hardware, which is a meaningful step up from a file on disk. If you are weighing that upgrade, the comparison of hardware security keys versus authenticator apps against phishing explains where each one fails. The same logic applies to how a FIDO2 PIN differs from an account password when a device falls into the wrong hands.
Key Types: RSA, ECDSA, and Ed25519
Not all keys are equal. The type you pick affects speed, key length, and compatibility with older servers.
RSA is the veteran. It works everywhere, including ancient appliances that never got updated, but modern guidance pushes key sizes to 3072 or 4096 bits, which makes signatures slower and files bigger.
ECDSA uses elliptic-curve math and produces shorter keys than RSA at comparable strength. It is widely supported but has a history of implementation quirks that make some security teams cautious.
Ed25519 is the current favorite for new keys. It is fast, produces compact keys, and avoids several classic pitfalls. OpenSSH added support for it in version 6.5, released in January 2014, according to the OpenSSH release notes.
In practice, most people should generate Ed25519 keys unless they must talk to a legacy system. A sensible default command looks like this:
- Open a terminal.
- Run ssh-keygen with the Ed25519 type and a comment that identifies the machine or purpose.
- Choose a file location, or accept the default in ~/.ssh/.
- Set a strong passphrase when prompted.
- Copy the.pub file to the server or paste it into your code host.
That is the entire ritual. The official ssh-keygen manual page documents every flag if you want to inspect, convert, or fingerprint existing keys.
Passphrases, Permissions, and the Mistakes People Make
Here is where first-timers trip. The private key file is only as safe as the disk it sits on, so a stolen laptop with an unprotected key is a stolen identity. A passphrase encrypts the private key at rest, which means an attacker who copies the file still needs to crack it.
Typing a passphrase for every connection gets old fast, so OpenSSH ships an agent that caches decrypted keys in memory for the session. The ssh-agent manual page explains how the cache works and how to forward it safely (short version: forward sparingly, because a compromised jump host can abuse a forwarded agent).
Permissions are the other classic failure. OpenSSH refuses to use a private key that other users can read, and the error message is famously unhelpful. The fix is to lock the file down to owner-only access, typically mode 0600, and keep the.ssh directory at 0700. The ssh manual page spells out which files matter and how host verification against known_hosts fits in.
Common mistakes worth avoiding:
- Generating a key without a passphrase because “it is just a test server,” then reusing it for years.
- Copying the private key to a server “for convenience.” The private key should never leave the machine that uses it.
- Pasting the private key into a chat window or ticket while trying to debug a login problem.
- Leaving old, unused public keys in authorized_keys long after a laptop was retired.
- Assuming a key that works for one account is scoped to that account. Keys are per-identity, not per-service.
Backups deserve their own paragraph. Losing a private key means losing access, and if it was the only way into a server, recovery can mean a console session or a support ticket. A planned approach, such as the one in this guide to a hardware security key backup strategy that avoids lockouts, applies just as well to software keys: keep an encrypted copy somewhere safe, and test that the backup actually works before you need it.
How SSH Keys Differ From Passwords and Certificates
People confuse three things that all involve “keys.” They are not the same.
A password is a shared secret. A key pair is an asymmetric secret where only one half is sensitive. A certificate wraps a public key in a signed statement that a trusted authority vouches for it.
SSH has its own trust model. When you connect to a server for the first time, your client shows a fingerprint and asks you to accept it. That fingerprint is the server’s host key. Accept it, and it gets pinned in known_hosts; if it ever changes, you get a loud warning about a possible man-in-the-middle attack. There is no browser-style certificate authority in the default flow, though SSH certificate authorities exist as an optional extension for large fleets.
That distinction matters when you are troubleshooting. A “host key verification failed” message is not about your login key at all. It is about the server’s identity, and the right response is to investigate, not to delete known_hosts and move on.
The same public-key idea shows up all over computing, from code signing to encrypted messaging. SSH just applies it to remote shells and file transfer, with a deliberately simple trust story.
Where SSH Keys Show Up in Daily Work
Keys are used beyond system administration. They are everywhere.
Version control is the big one. Pushing to a code host over SSH uses a key instead of a password, which is why your first push sometimes fails with a permission error until the public key is added to your account.
Automation depends on keys too. Deployment scripts, backup jobs, and configuration tools log in without a human present, so they use dedicated keys with narrow permissions. The discipline here is to give each job its own key, restrict what it can do, and rotate it when the job changes.
File transfer tools, database tunnels, and infrastructure dashboards all lean on the same mechanism. Even some smart-home and networking gear accepts SSH keys for administrative access, which is a good reason to treat your key file like a house key rather than a password reminder.
One more angle worth knowing: the way you protect a key file is not so different from the way you protect a physical door. A lock with a mechanical override still needs a plan for what happens when the electronics fail, which is why guides on a smart lock with a physical key backup make the same argument keys do: redundancy beats a single point of failure. The same reasoning explains why a free antivirus versus a paid one is a trade-off question, not a moral one. Security is always about layered choices.
Practical Setup Checklist
If you are setting up keys for the first time, work through this in order. It takes about ten minutes and saves hours later.
- Check whether you already have keys in ~/.ssh/. Reusing an existing one is fine for personal use, but separate keys per purpose are cleaner.
- Generate a new Ed25519 key with a descriptive comment.
- Set a strong passphrase and store it in a password manager.
- Fix permissions on the private key and the.ssh directory.
- Copy the public key to the target server or code host.
- Test the login, then test it again after a reboot to confirm the agent and config behave.
- Make an encrypted backup of the private key and store it offline.
- Disable password authentication on servers once key login is confirmed working, if policy allows.
Step eight is where people get nervous, and rightly so. Test with a second session open before you change the server config, so a mistake does not lock you out.
Conclusion
An SSH key is a pair of mathematically linked secrets that let you prove your identity without sending a password across the network. The public half is shareable and lives on servers; the private half stays on your machine and signs challenges. Ed25519 is the sensible default for new keys, a passphrase protects the file at rest, strict permissions keep OpenSSH happy, and a tested backup keeps you from locking yourself out. Once you internalize the public-versus-private split, every error message and setup guide suddenly makes sense.
Frequently Asked Questions
Can I use the same SSH key for multiple servers?
Yes, and most people do. A single key pair can be authorized on many servers and code hosts. The trade-off is blast radius: if that one private key is stolen, every system that trusts it is exposed. High-value environments often use separate keys per purpose so a compromise stays contained.
What happens if I lose my private key?
You lose key-based access to everything that trusts it. Recovery means using another credential, a console session, or a support process to install a new public key. This is why an encrypted offline backup of the private key matters, and why you should test that backup before you need it.
Is an SSH key safer than a password?
Generally yes, for remote login. The private key never crosses the network, so there is nothing reusable to intercept, and brute-force guessing does not apply the way it does to passwords. The caveat is that an unprotected private key file on a stolen laptop is just as dangerous as a written-down password, so passphrase protection is essential.
Should I pick Ed25519 or RSA?
Pick Ed25519 for new keys unless you must connect to old hardware or software that does not support it. It is faster, produces shorter keys, and is well supported in modern OpenSSH. RSA remains the compatibility fallback, and if you use it, choose at least 3072 bits.
Why does SSH complain about permissions on my private key?
OpenSSH refuses to use a private key that other users on the machine can read, because that would defeat the point of keeping it secret. Restrict the file to owner-only access, typically mode 0600, and the warning disappears. It is a safety feature, not a bug.
What is the difference between a host key and my user key?
Your user key proves who you are to the server. The host key proves the server’s identity to you, and your client pins it in known_hosts the first time you connect. A changed host key warning is about the server, not your login credentials, and it deserves investigation rather than a quick deletion.
