Every time you type a password into an SSH session, somewhere a security engineer feels a disturbance in the Force.
Also Read
Passwords can be guessed, brute-forced, phished, and reused. Yet the alternative — SSH keys — is free, built into every system you own, and takes about five minutes to set up. This guide is those five minutes, plus everything worth understanding around them.
Quick answer: SSH key authentication replaces passwords with a mathematically linked pair of keys: a private key that never leaves your computer, and a public key you place on the server. When you connect, the server issues a challenge only your private key can answer — proving your identity without any secret crossing the network. It’s dramatically more secure than passwords and, once set up, more convenient too.
Key Takeaways
- SSH keys come in pairs: private (stays with you, secret) and public (goes on servers, shareable).
- Authentication is a challenge–response: the private key proves itself without ever being transmitted.
- Keys are immune to brute-force guessing in any practical sense — unlike even “strong” passwords.
- Generate a modern key with one command:
ssh-keygen -t ed25519. - Always add a passphrase to your private key, and let an SSH agent handle the convenience.
- Once keys work, disable password login on your server — that’s when the security payoff lands.
A 60-Second Refresher: What Is SSH Again?
SSH (Secure Shell) is the encrypted protocol for remotely controlling another computer — the standard way developers and admins manage servers, and the transport underneath tools like SFTP, Git pushes, and rsync.
We’ve covered the protocol itself in our full guide to what SSH is and how it works. This article zooms into the part that matters most for security: how you prove who you are.
SSH gives you two main options for that proof: a password, or a key pair. One of them is 1995 technology behaving like it; the other is the industry standard for a reason.
What’s Wrong With Password Authentication?
Nothing — if your server never faces the internet. For everything else, the problems stack up fast:
Brute-force is constant. Any server with an open SSH port gets hammered around the clock by bots guessing passwords. Watch a fresh server’s logs for an hour and you’ll see the attempts roll in from around the world.
Humans choose human passwords. Memorable means guessable. And the strong ones get reused across systems, so one leak becomes many.
Passwords travel. The password itself is sent to the server (inside encryption, but still sent) — so a compromised or impersonated server can capture it.
Phishing works. Anything a human can type, a human can be tricked into typing somewhere wrong.
Keys eliminate every one of these categories at once. Not reduce — eliminate.
How Does Public-Key Cryptography Work, in Plain English?
Here’s the beautiful idea underneath, no math degree required.
A key pair is two files generated together, linked by mathematics with a special one-way property: what one key locks, only the other can unlock — and knowing the public key doesn’t let anyone compute the private one.
Think of the public key as a padlock and the private key as its only key. You can hand copies of your padlock to every server in the world; only you can open what they lock with it.
That asymmetry is why sharing your public key is completely safe — it’s in the name. The private key, meanwhile, is the crown jewel: it never leaves your machine, ever.
What Actually Happens When You Log In With a Key?
The login handshake takes milliseconds, but here’s the plain-English play-by-play:
1. Hello. Your computer connects and says which public key it wants to use.
2. The server checks its guest list. It looks in the account’s authorized_keys file. If your public key isn’t listed, game over.
3. The challenge. The server generates a random puzzle and encrypts it using your public key — producing a ciphertext only the matching private key can decrypt.
4. The proof. Your machine decrypts the challenge with your private key and sends back the correct response.
5. Welcome. The server now knows — with mathematical certainty — that you hold the private key. Session opens.
Notice what never happened: no secret crossed the wire. Every challenge is different, so recordings are useless. There is nothing to guess, phish, or replay. That’s the whole trick — and it’s why security teams treat keys as the baseline.
How Do You Generate an SSH Key Pair?
One command, any modern system (Linux, macOS, or Windows 10/11 with OpenSSH built in):
ssh-keygen -t ed25519 -C "your-label-here"
Walking through the prompts:
File location: accept the default (~/.ssh/id_ed25519) unless you manage multiple keys deliberately.
Passphrase: set one (more on why below).
That’s it. You now own two files: id_ed25519 (private — guard it) and id_ed25519.pub (public — hand it out freely).
The -C comment is just a label — an email or “work-laptop-2026” — that helps you identify the key later in server files.
Ed25519 or RSA: Which Key Type Should You Choose?
Short version: Ed25519 for everything modern.
It’s the current default recommendation — fast, compact, and strong. RSA (at 4096 bits: ssh-keygen -t rsa -b 4096) remains perfectly secure and matters mainly for compatibility with old systems that predate Ed25519 support.
Two types you may see referenced and should skip: DSA (deprecated, refuse it) and ECDSA (fine, but Ed25519 is generally preferred).
Practical rule: generate Ed25519; keep an RSA-4096 key only if some legacy device forces your hand.
How Do You Put Your Public Key on a Server?
Three ways, from easiest to most manual:
The one-command way
ssh-copy-id user@your-server — logs in with your password one final time and installs your public key correctly. Linux and macOS include it.
The control-panel way
Most hosting dashboards (hPanel, cPanel, cloud consoles) have an “SSH Keys” page: paste the contents of your .pub file, save, done. This is the route on most shared and managed hosting.
The manual way
Append your public key as one line to ~/.ssh/authorized_keys on the server. If you create the file or folder, permissions matter: 700 for ~/.ssh, 600 for authorized_keys — SSH refuses sloppy permissions by design.
Then test: ssh user@your-server should drop you in without a password prompt (or asking only for your key’s passphrase — different thing, explained next).
Why Bother With a Passphrase on the Key?
Because private keys are files, and files get stolen — laptop theft, malware, a mis-synced backup folder.
A passphrase encrypts the private key itself. A thief with your key file but not the passphrase has an expensive paperweight.
“But I chose keys to stop typing passwords!” — correct, and you still will: that’s what the SSH agent is for. The agent (built into macOS, Linux, and Windows) holds your unlocked key in memory after you enter the passphrase once per session — every connection after that is instant.
Passphrase + agent = maximum security with zero daily friction. It’s the correct default, not the paranoid option.
The Final Boss Move: Disabling Password Login
Once your key works, the real security upgrade is turning password authentication off on the server — closing the brute-force door permanently.
In /etc/ssh/sshd_config, set PasswordAuthentication no, then reload the SSH service.
The golden rule: keep your current session open and verify key login in a second terminal before you disable passwords. Every admin who skipped that step has a locking-themselves-out story.
From that moment, the bots hammering your port are guessing passwords at a door that no longer has a keyhole. Your logs get boring — the good kind of boring. (Pair it with the basics in our site security guide and 2FA explainer for defense in depth.)
How Do You Manage Keys for Multiple Servers and Services?
Reality check: you’ll soon have keys for a VPS, GitHub, a work server, and a client’s box. The ~/.ssh/config file keeps it civilized:
A config entry gives each destination a nickname, a key, and a user — so ssh myblog replaces a long incantation. One block per host, a few lines each.
Strategy question — one key everywhere, or one per service? A sensible middle ground for most people: one key per device you work from (laptop, desktop), revoking a device’s key everywhere if that device is lost. High-security contexts go per-service; the important part is knowing what exists where.
Audit habit: the authorized_keys file on each server is the guest list — skim it occasionally and evict keys you no longer recognize.
Where Else Do SSH Keys Show Up?
Git hosting. GitHub, GitLab, and Bitbucket authenticate pushes over SSH keys — the same .pub file pasted into your account settings. If you’ve ever pushed code without typing a password, a key was working.
Automated jobs. Backups, deploy scripts, and CI pipelines authenticate with keys because no human is present to type anything.
File transfer. SFTP and rsync ride on SSH — your key covers them automatically.
Hosting management. Any decent host offering shell access supports keys; it’s a checkbox worth looking for when choosing where your projects live. our budget pick with full SSH and key support across plans is Hostinger.
Check Hostinger plans →
Common SSH Key Errors (and Their Fixes)
“Permission denied (publickey)” — the classic. Usual causes: your public key isn’t in the server’s authorized_keys, you’re connecting as the wrong user, or SSH is offering a different key than you think. Add -v to the ssh command to watch the negotiation.
“Bad permissions” / key ignored — SSH refuses keys that other users could read. Fix: chmod 700 ~/.ssh and chmod 600 on private keys and authorized_keys.
Asked for a password anyway — either the key exchange failed (see above) or you’re being asked for the key’s passphrase, which is normal and solved daily by the agent.
Works from one machine, not another — keys don’t follow you; each device has its own. Generate a key on the new machine and add its public half to the server.
SSH Key Security Best Practices
- Never share or email a private key. If it left your machine, treat it as compromised — generate fresh.
- Passphrase every key, agent for convenience.
- One key per device, so a lost laptop means one revocation, not identity surgery.
- Back up privately: if you back up keys at all, only into encrypted storage.
- Rotate on events, not calendars: a device change, a departure, a suspicion — that’s when keys change.
- Prune guest lists: old keys in
authorized_keysare standing invitations. Delete what you don’t recognize. - Keep the private key out of cloud-synced folders unless the folder is genuinely encrypted.
For the deeper protocol mechanics, DigitalOcean’s SSH encryption walkthrough is an excellent next read.
Common Myths About SSH Keys
“Keys are for experts.” The setup is one command and one paste. If you can install WordPress, you can install a key.
“A strong password is just as good.” No password survives contact with modern brute-force economics the way a 256-bit key does — and passwords can be phished; keys can’t be typed into a fake site.
“If someone gets my public key, I’m hacked.” The public key is designed to be public — it can’t be reversed into the private key. Guard the private file; share the padlock freely.
“Keys expire.” Standard SSH keys don’t expire on their own — which is exactly why you must do the housekeeping when devices and people move on.
“I have 2FA, so keys don’t matter.” They solve different layers — and combine beautifully. Keys stop credential attacks; 2FA guards interactive logins. Serious setups use both.
Frequently Asked Questions
What is SSH key authentication?
A login method using a mathematically linked key pair: a private key kept on your device and a public key placed on the server. The server verifies you through a cryptographic challenge only your private key can answer — no password sent, nothing to guess or phish.
Are SSH keys safer than passwords?
Substantially. Keys are immune to practical brute-force guessing, can’t be phished into a fake prompt, and never transmit a reusable secret. Passwords fail on all three counts, which is why bots attack password-enabled SSH ports continuously.
How do I generate an SSH key?
Run ssh-keygen -t ed25519 in a terminal (Linux, macOS, and modern Windows all include it), accept the default location, and set a passphrase. You’ll get a private key file and a shareable .pub public key file.
What is the difference between a public and private SSH key?
They’re generated as a linked pair. The public key works like a padlock you copy onto any server; the private key is the only key that opens it and never leaves your machine. Sharing the public key is safe by design.
Should I put a passphrase on my SSH key?
Yes. The passphrase encrypts the private key file, so a stolen laptop or leaked backup doesn’t hand over server access. An SSH agent remembers the unlocked key per session, so daily use stays password-free.
What does “Permission denied (publickey)” mean?
The server refused every key your client offered — usually because your public key isn’t in the account’s authorized_keys file, you used the wrong username, or file permissions on the server are too loose. Run ssh with -v to see the details.
Can I use the same SSH key for GitHub and my server?
Technically yes — the same public key can authorize you anywhere. A tidier habit is one key per device: add that device’s key to GitHub and your servers, and revoke it everywhere if the device is ever lost.
The bottom line
SSH keys are the rare security upgrade that also improves your day: five minutes of setup buys mathematically sound logins, silence from brute-force bots, and never typing a server password again. Generate the pair, copy the public half, passphrase the private one, disable passwords — and join the side of the Force your logs will thank you for.
Khan Nasir
