Secure SSH Public‑Key Authentication: From Generation to Verification

Why Key‑Based SSH Matters

When you need to log into a server, using a password exposes you to brute‑force attacks, credential theft, and accidental disclosure. Public‑key authentication replaces the password with a cryptographic challenge that only your private key can answer, making the login process both safer and more convenient. The core steps are: generate a key pair, distribute the public key, configure the server, and verify that the client uses the key.

Step 1 – Generate a Modern Key Pair

OpenSSH ships with several algorithms, but ed25519 is the most compact and offers strong security with a short key. Run:

ssh-keygen -t ed25519 -C "user@myserver" -f ~/.ssh/id_ed25519

Replace user@myserver with a descriptive comment. The command creates two files:

• ~/.ssh/id_ed25519 – the private key (keep it secret)
• ~/.ssh/id_ed25519.pub – the public key you will copy to the remote host

Verify permissions: chmod 600 ~/.ssh/id_ed25519. OpenSSH will refuse a key that is world‑readable.

Step 2 – Add the Public Key to the Server

On the target machine, ensure the user’s ~/.ssh directory exists and is owned by that user:

mkdir -p ~/.ssh
chown $USER:$USER ~/.ssh
chmod 700 ~/.ssh

Append the public key to ~/.ssh/authorized_keys:

cat /path/to/id_ed25519.pub >> ~/.ssh/authorized_keys
chown $USER:$USER ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Each key occupies its own line. Do not use chmod 644 on authorized_keys; the server will reject it.

Step 3 – Harden the Server Configuration

Edit /etc/ssh/sshd_config (or the equivalent on your distro). Add or adjust the following directives:

PubkeyAuthentication yes
# Optional – enforce key‑only access
#PasswordAuthentication no
#DisablePasswordAuthentication yes  # same effect as above

After editing, reload the SSH daemon:

sudo systemctl reload sshd

If PubkeyAuthentication is set to no, key logins will fail even if the key is present.

Step 4 – Connect With the Key

From the client machine, use:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@remote-host

The -o IdentitiesOnly=yes option forces the client to use only the specified key, preventing the agent from offering other keys that might be accepted elsewhere. If you have multiple keys, this avoids accidental credential leakage.

Step 5 – Verify the Authentication Path

Run the connection in verbose mode:

ssh -vvv user@remote-host

Look for:

• debug1: Authentications that can continue: publickey
• debug1: Offering public key

On the server, check the authentication log (e.g., /var/log/auth.log on Debian/Ubuntu or /var/log/secure on RHEL/CentOS):

grep "Accepted publickey" /var/log/auth.log

Each successful key login should appear as Accepted publickey for user from IP.

Common Mistakes to Avoid

• Wrong file permissions – authorized_keys must be 600 and owned by the user; ~/.ssh must be 700. Any deviation causes SSH to reject the file.
• Using the same key on many hosts – if a key is compromised, all hosts that accept it are at risk. Generate a unique key pair per host or per service when possible.
• Leaving the private key world‑readable – chmod 644 ~/.ssh/id_ed25519 will make OpenSSH refuse to use it.
• Ignoring PubkeyAuthentication setting – if the server config disables public‑key auth, key logins will never succeed regardless of authorized_keys.
• Not testing after changes – always verify with ssh -vvv and check logs before assuming the configuration is effective.

Limitations and Practical Checks

• Agent forwarding risks – if you enable ForwardAgent yes, any host you connect to can use your key to reach other hosts. Disable agent forwarding unless you trust the intermediate host.
• Key revocation – if you lose a private key, remove the corresponding public key from authorized_keys on all affected servers immediately.
• Key size and algorithm support – older servers may not support ed25519. Fall back to rsa with -b 4096 if necessary.
• Backup strategy – store the private key in a secure, encrypted vault or hardware token; never commit it to source control.

Conclusion

Implementing SSH public‑key authentication is a straightforward process that dramatically improves security. By generating a modern key pair, correctly configuring both client and server, and rigorously verifying the setup, you eliminate password‑based vulnerabilities while maintaining a smooth login experience.