SSH Key Based Authentication: Setup and Best Practices

SSH Series: Part 3
SSH key based authentication improves server security by replacing password logins with public/private key pairs. This guide explains how to generate SSH keys, install the public key, test access, and protect the private key.

SERIES: SSH

SSH key based authentication

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:

  1. You generate a key pair on your local machine.
  2. You copy the public key to the server.
  3. The server stores it in ~/.ssh/authorized_keys.
  4. During login, your SSH client proves it has the matching private key.
  5. 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.


Work Behind The Writing

This article comes from real-world AI and DevOps engineering work.

If the thinking here is useful, explore the projects behind it or get in touch about a similar technical problem.
comments powered by Disqus