SSH Key Based Authentication

SSH Series: Part 3
Posted by Munish Mehta on Thursday, January 23, 2025
Secure Shell is all about convenience and security. Once you get comfortable with these essentials, you’ll be well on your way to harnessing the full power of SSH!

This article is part of a series.

ssh 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

  1. 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 (for ED25519), or similarly large, making them extraordinarily difficult to brute force in any realistic timeframe.

  2. 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.

  3. 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.

  4. 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.

ssh

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. Replace ed25519 with rsa 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:

  1. File location: The default is ~/.ssh/id_ed25519 (or id_rsa if RSA).
  2. 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.

Once you verify that key-based logins work (see Step 4 below), you can turn off password authentication for an extra layer of security.

  1. Edit /etc/ssh/sshd_config

    sudo nano /etc/ssh/sshd_config
    
  2. Set the following directives:

    PasswordAuthentication no
    ChallengeResponseAuthentication no
    UsePAM no
    
  3. 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

  1. 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.
  2. 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.
  3. Use ED25519 Where Possible

    • ED25519 offers robust security with shorter key sizes and faster performance. It’s widely supported in modern systems.
  4. Restrict File Permissions

    • Ensure ~/.ssh/authorized_keys on the server is set to 600 (owner read-write) and ~/.ssh/ directory is 700.
    • On the client, also keep private keys to 600.
  5. 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.
  6. 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.

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.


comments powered by Disqus