This article is part of a series.
- SSH Series
- Part 1: Introduction to SSH
- Part 2: Setting Up and Using SSH
- Part 3: SSH Key Based Authentication
- Part 4: SSH Best Practices and Security Hardening
- Part 5: Advanced SSH Techniques
- Part 6: Troubleshooting Common SSH Issues
- Part 7: Automating Tasks With Automation
- Part 8: SSH Alternatives and Enhancements
- Part 9: Recap, Further Resources, and Closing Thoughts
In our previous posts, I covered the basics of SSH and how to set it up across various operating systems. Now, it’s time to take a significant step forward in security. Key-based authentication is not only more secure than using plain passwords, it also provides a smoother login experience once it’s configured. In this guide, I’ll explore why key-based authentication is more secure, how to generate SSH keys, and configure a server to use those keys.
Why Keys Are More Secure Than Passwords
-
Harder to Crack A password can be guessed or brute-forced, especially if it’s short or reused from another service. SSH keys, by contrast, are typically 1024+ bits (for
RSA
), 256 bits (forED25519
), or similarly large, making them extraordinarily difficult to brute force in any realistic timeframe. -
No Typing Required Once the keys are set up, you don’t have to type a password for each login (unless you choose to secure your private key with a passphrase, which I recommend). This reduces the risk of keyloggers capturing your credentials.
-
Separate Authentication Factors If an attacker somehow learns your username, they still need your private key file to gain access. Simply knowing a password isn’t enough, and the private key file should ideally be on a secure local machine.
-
Easier to Manage Keys can be easily revoked (by removing them from the
authorized_keys
file on the server) if a user leaves an organization or a laptop is lost. There’s no need to change server-wide passwords.

Generating SSH Keys
SSH supports multiple public key algorithms. The most common are RSA and ED25519, each with its own advantages:
- RSA: A traditional choice.
- Typically, use 2048 or **4096-**bit keys
- Widely compatible with nearly all systems.
- ED25519: A modern elliptical-curve algorithm.
- Keys are shorter but offer strong security.
- Faster key generation and signing; generally considered more secure than RSA at comparable sizes.
Command to Generate SSH Keys
On Linux or macOS
- open a terminal and run:
ssh-keygen -t ed25519 -C "your_email@example.com"
-t ed25519
specifies the key type. Replaceed25519
withrsa
if you prefer RSA.-C "your_email@example.com"
is a comment field, helping identify which key belongs to whom.
You’ll be prompted for:
- File location: The default is
~/.ssh/id_ed25519
(orid_rsa
if RSA). - Passphrase: Highly recommended to protect your private key if someone gains access to your machine.
Example output of ssh-keygen
command:
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
You’ll end up with:
- Private key:
~/.ssh/id_ed25519
- Public key:
~/.ssh/id_ed25519.pub
[!tip] Never share your private key. The public key (
.pub
) is the one you copy to servers.
Configuring Your Server for Key-Based Authentication
After generating your key pair on the client machine, you need to add the public key to the server you want to access.
Copy Your Public Key to the Server
Method 1:
Using ssh-copy-id
(Linux/macOS) to copy public key
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip
- This will prompt for your password (the one set on the server), then add the public key to
~/.ssh/authorized_keys
on the server.
Method 2
Manually Copying the Key
-
View the contents of your public key file
cat ~/.ssh/id_ed25519.pub
-
SSH into the server using your password
ssh user@server-ip
-
Append the public key to
authorized_keys
echo "ssh-ed25519 AAAAC3NzaC1..." >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys
Replace "ssh-ed25519 AAAAC3NzaC1..."
with the output you copied from your .pub
file.
Disable Password Authentication (Optional but Recommended)
Once you verify that key-based logins work (see Step 4 below), you can turn off password authentication for an extra layer of security.
-
Edit
/etc/ssh/sshd_config
sudo nano /etc/ssh/sshd_config
-
Set the following directives:
PasswordAuthentication no ChallengeResponseAuthentication no UsePAM no
-
Restart
SSH
sudo systemctl restart ssh
OR
sudo service ssh restart
This ensures the server only accepts key-based logins.
Testing Your Key-Based Login
Once the public key is installed on the server, try logging in:
ssh -i ~/.ssh/id_ed25519 user@server-ip
-i
specifies the private key to use if it’s not the default name (id_ed25519
).- If you used a passphrase when generating the key, you’ll be prompted for it. Otherwise, you should log in without a password prompt.
If everything’s set up correctly, you’ll be greeted with the server shell!
Best Practices and Tips
-
Use a Passphrase
- Setting a passphrase on your private key adds an extra layer of protection. If someone steals your key file, they still need the passphrase to use it.
-
Backup Your Keys Securely
- Losing your private key could lock you out of servers, especially if you’ve disabled password logins. Keep encrypted backups or store them in a secure password/key manager.
-
Use ED25519 Where Possible
- ED25519 offers robust security with shorter key sizes and faster performance. It’s widely supported in modern systems.
-
Restrict File Permissions
- Ensure
~/.ssh/authorized_keys
on the server is set to600
(owner read-write) and~/.ssh/
directory is700
. - On the client, also keep private keys to
600
.
- Ensure
-
Limit SSH Access
- Consider restricting SSH to certain users or groups, and use a firewall (like
ufw
or iptables) to allow inbound connections on port 22 only from trusted addresses.
- Consider restricting SSH to certain users or groups, and use a firewall (like
-
Consider SSH Config File
- On the client machine, you can simplify repeated commands by editing
~/.ssh/config
. For example:
Host myserver HostName 192.168.1.100 User myuser Port 22 IdentityFile ~/.ssh/id_ed25519
- Then simply run
ssh myserver
.
- On the client machine, you can simplify repeated commands by editing
Conclusion
SSH key-based authentication is a must-have skill for any sysadmin or developer who deals with remote servers. It not only strengthens security against brute force attacks but also streamlines your workflow by removing the need to type passwords. With algorithms like ED25519, you can enjoy state-of-the-art encryption that’s fast and easy to manage.
In the next part of our series, I’ll delve into security hardening and other best practices—like changing default ports, disabling root login, and using tools like Fail2Ban to lock out suspicious IP addresses. Stay tuned!
Further Reading
Have questions or want to share your own SSH key tips? Leave a comment below, and let’s keep the conversation going.
This article is part of a series.
- SSH Series
- Part 1: Introduction to SSH
- Part 2: Setting Up and Using SSH
- Part 3: SSH Key Based Authentication
- Part 4: SSH Best Practices and Security Hardening
- Part 5: Advanced SSH Techniques
- Part 6: Troubleshooting Common SSH Issues
- Part 7: Automating Tasks With Automation
- Part 8: SSH Alternatives and Enhancements
- Part 9: Recap, Further Resources, and Closing Thoughts
comments powered by Disqus