Implementing SSH Public Key Authentication for Passwordless Secure Access

The Problem: Password Vulnerability and Management Overhead

Relying on passwords for remote server access introduces two primary risks: susceptibility to brute-force attacks and the operational burden of managing complex credentials across multiple environments. Public Key Authentication solves this by replacing a shared secret (the password) with a cryptographic proof of identity, ensuring that only holders of a specific private key can gain entry.

How Public Key Authentication Works

This method uses asymmetric cryptography. You generate a key pair consisting of a public key (which can be shared openly) and a private key (which must never leave your local machine).

When you attempt to connect, the server sends a challenge encrypted with your public key. Your SSH client uses the corresponding private key to sign this challenge. If the signature is valid, the server grants access. Because the private key is never transmitted over the network, an attacker cannot intercept it during the handshake.

Implementation Guide

This guide assumes the use of OpenSSH (version 8.0 or newer) on both the client and server.

1. Generate a Modern Key Pair

Avoid legacy RSA keys if possible. Ed25519 is currently recommended for its superior security and performance.

# Run this on your local workstation
ssh-keygen -t ed25519 -C "user@workstation-name"

Key Decisions:

• Passphrase: When prompted, enter a strong passphrase. This encrypts the private key on your disk, meaning that if your laptop is stolen, the thief cannot use the key without the passphrase.
• File Location: The default ~/.ssh/id_ed25519 is standard and recognized by most clients.

2. Deploy the Public Key to the Server

The server must know your public key to verify your identity. The public key is stored in a specific file on the server: ~/.ssh/authorized_keys.

# Run this on your local workstation
# Replace 'user' and 'server-ip' with your actual credentials
ssh-copy-id user@server-ip

If ssh-copy-id is unavailable, you must manually append the contents of your id_ed25519.pub file to the remote ~/.ssh/authorized_keys file, ensuring it exists on a single line.

3. Verify the Connection

To ensure the server is using the key rather than falling back to a password, force the authentication method:

# Run this on your local workstation
ssh -o PreferredAuthentications=publickey user@server-ip

If you are prompted for your passphrase (local) rather than your user password (remote), the configuration is successful.

Critical Constraints and Common Failures

Filesystem Permissions

SSH is designed to fail if permissions are too open, as this would allow other local users to steal or modify your keys. If you see "Permission denied" despite having the correct keys, check these settings:

Location	Required Permission	Reason
Client: ~/.ssh/id_ed25519	600 (rw-------)	Private key must be readable only by the owner.
Server: ~/.ssh/	700 (rwx------)	Directory must be private to prevent unauthorized key injection.
Server: ~/.ssh/authorized_keys	600 or 644	Must be readable by the SSH daemon.

Algorithm Deprecation

Older systems may use ssh-rsa (based on SHA-1). Many modern OpenSSH versions disable this by default because SHA-1 is cryptographically weak. If you are connecting to an older legacy server and your key is rejected, you may need to generate an RSA key specifically or update the server's OpenSSH version.

The Lockout Risk

Once public key authentication is verified, administrators often disable password authentication in /etc/ssh/sshd_config by setting PasswordAuthentication no. Warning: If you lose your private key or delete it from your local machine, you will be permanently locked out of the server unless you have an alternative access method (such as a cloud provider's web console or physical access).

Rollback Procedure

If you need to revoke access for a specific key or return to password-based access:

1. Log into the server.
2. Open ~/.ssh/authorized_keys and delete the line containing the specific public key you wish to revoke.
3. To re-enable passwords, edit /etc/ssh/sshd_config, set PasswordAuthentication yes, and restart the service: sudo systemctl restart ssh.