If you’re typing a password every time you SSH into a box, you’re doing it the slow way and the less secure way.
I manage 18 Linux hosts. If I had to type a password for each one, every single time, I would lose my mind. SSH keys solve that problem. You generate a key pair once, deploy the public key to your servers, and from then on, logging in is instant and password-free.
But speed is not the only reason. Key-based authentication is also more secure than passwords. Keys are long, random, and never sent over the network. Nobody can brute force a 4096-bit RSA key the way they can brute force “Summer2026!” over SSH.
How SSH Keys Work
An SSH key pair has two halves:
- Private key stays on your machine. Never share it. Never copy it to a server.
- Public key goes on every server you want to access. It’s safe to share.
When you connect, your machine proves it has the private key without sending it. The server checks against the public key it has on file. If they match, you’re in. No password transmitted, no password to intercept.
Generating a Key Pair
On your local machine (the one you SSH from), run:
ssh-keygen -t ed25519 -C "your-name@your-machine"
It will ask where to save it. The default (~/.ssh/id_ed25519) is fine. It will also ask for a passphrase. Set one. If someone steals your private key file, the passphrase protects it.
This creates two files:
~/.ssh/id_ed25519(private key, keep this safe)~/.ssh/id_ed25519.pub(public key, deploy this to servers)
If you need RSA compatibility with older systems:
ssh-keygen -t rsa -b 4096 -C "your-name@your-machine"
Deploying Your Public Key
The fastest way to get your public key onto a remote server:
ssh-copy-id user@server-ip
This logs in with your password one last time, copies your public key to the server’s ~/.ssh/authorized_keys file, and sets the correct permissions. After this, password-free login works.
If ssh-copy-id is not available, you can do it manually:
cat ~/.ssh/id_ed25519.pub | ssh user@server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Testing It
ssh user@server-ip
If it logs in without asking for a password (or only asks for your key passphrase), it’s working.
Disabling Password Authentication
Once keys are working on all your servers, you can disable password login entirely. This means nobody can brute force passwords over SSH because the option does not exist.
On the remote server, edit /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes
Then restart SSH:
sudo systemctl restart sshd
Make sure your key login works before doing this. If you disable passwords and your key is broken, you will be locked out.
Managing Multiple Keys
If you work with different environments (home, work, client servers), you can generate separate keys for each and tell SSH which one to use. Add entries to ~/.ssh/config:
Host homelab
HostName 192.168.1.100
User dennis
IdentityFile ~/.ssh/id_ed25519
Host work-server
HostName 10.0.0.50
User admin
IdentityFile ~/.ssh/id_rsa_work
Now ssh homelab connects with the right key, user, and address automatically.
Common Mistakes
- Wrong permissions. SSH is strict about file permissions. Your
.sshdirectory should be 700, your private key 600, andauthorized_keys600. If permissions are too open, SSH refuses to use the key silently. - Copying the private key to servers. Never do this. Only the public key goes on remote machines.
- No passphrase on the private key. If your laptop gets stolen and your key has no passphrase, the thief has access to everything. Use a passphrase and let
ssh-agentcache it so you only type it once per session. - Forgetting to test before disabling passwords. Always confirm key login works from a separate terminal before you turn off password auth.
Links
Using Windows instead? See the Windows post: SSH Keys on Windows 11: Native OpenSSH Without the Extra Tools