SERIES: SSH
- Part : Recap, Further Resources, and Closing Thoughts
- Part : SSH Alternatives and Enhancements
- Part : Automating Tasks With Automation
- Part : Troubleshooting Common SSH Issues
- Part : Advanced SSH Techniques: Tunnels, Jump Hosts, SSHFS, and Multiplexing
- Part : SSH Best Practices and Security Hardening
- Part : SSH Key Based Authentication: Setup and Best Practices
- Part : Setting Up and Using SSH
- Part : What Is SSH? A Practical Introduction to Secure Shell
- SSH Series

Quick answer: SSH key based authentication uses a public/private key pair instead of a password. The public key sits on the server, the private key stays on your machine, and SSH verifies that the two match during login.
This is usually safer than password-only SSH because an attacker cannot log in just by guessing or stealing a password. They also need the private key, and ideally the passphrase that protects that key.
If you are new to SSH itself, start with What Is SSH? A Practical Introduction to Secure Shell first.
Why SSH Keys Are Better Than Passwords
Passwords are easy to reuse, guess, phish, or brute force. SSH keys are harder to attack because the private key never needs to be sent to the server.
Key based authentication gives you:
- stronger protection against brute-force password attacks
- smoother logins once configured
- easier access control by adding or removing public keys
- support for automation without storing plaintext passwords
- a better foundation for hardened SSH servers
The important rule is simple: share the public key, protect the private key.
How SSH Key Authentication Works
The flow is:
- You generate a key pair on your local machine.
- You copy the public key to the server.
- The server stores it in
~/.ssh/authorized_keys. - During login, your SSH client proves it has the matching private key.
- The server grants access if the proof is valid.
The private key should stay on your local machine. Do not paste it into servers, tickets, chats, or documentation.
Generate an SSH Key Pair
For modern systems, I usually prefer ED25519 keys:
ssh-keygen -t ed25519 -C "your_email@example.com"
This creates:
- private key:
~/.ssh/id_ed25519 - public key:
~/.ssh/id_ed25519.pub
Use a passphrase when prompted. A passphrase protects the private key if the file is copied or stolen.
RSA is still common in older environments:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Use ED25519 where possible and RSA only when compatibility requires it.
Copy the Public Key to the Server
The easiest method on Linux or macOS is ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip
That appends your public key to the server’s authorized_keys file.
If ssh-copy-id is not available, copy the public key manually:
cat ~/.ssh/id_ed25519.pub
Then on the server:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
Paste only the public key into authorized_keys.
Test SSH Key Login
Test the connection before disabling password login:
ssh -i ~/.ssh/id_ed25519 user@server-ip
If the private key has a passphrase, you will be prompted for it. If the server accepts the key, you should reach the shell without entering the account password.
Do not close your existing admin session until the new key login works.
Disable Password Authentication Carefully
After key login works, you can harden the server by disabling password authentication.
Edit the SSH server config:
sudo nano /etc/ssh/sshd_config
Set:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
Then restart SSH:
sudo systemctl restart ssh
Keep another terminal open while testing. A bad SSH config can lock you out.
SSH Key Best Practices
Use these habits:
- use ED25519 keys where supported
- protect private keys with passphrases
- keep private key permissions restricted
- remove old public keys from
authorized_keys - use separate keys for different machines or roles when useful
- avoid sharing one private key across many people
- back up important private keys securely
File permissions matter:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/authorized_keys
Loose permissions can cause SSH to ignore the key for safety reasons.
Where This Fits in the SSH Series
SSH keys are the bridge between basic SSH usage and serious SSH hardening.
Useful next reads:
Final Takeaway
SSH key based authentication is one of the simplest upgrades you can make to server access.
Generate a strong key, protect the private half, install only the public half on the server, test login before locking anything down, and then disable password authentication when you are confident the key path works.