SSH Public‑Key Authentication: Secure, Passwordless Remote Access Made Simple

The Core Benefit: Passwordless Secure Access

When you can log into a remote machine without typing a password, you cut two major security risks at once: you eliminate password‑guessing attacks and you avoid storing passwords on the client. SSH public‑key authentication replaces the traditional password prompt with a cryptographic challenge that only the holder of the private key can satisfy.

How SSH Public Key Authentication Works

Key Pair Generation

The client creates an asymmetric key pair. The private key stays on the client; the public key is copied to the server. Modern OpenSSH recommends ed25519 for its speed and security:

# run on the client
ssh-keygen -t ed25519 -C "${USER}@${HOST}" -f ~/.ssh/id_ed25519
# you will be prompted for a passphrase (optional)

The command outputs two files: id_ed25519 (private) and id_ed25519.pub (public).

Deploying the Public Key

On the destination host, the public key must be appended to ~/.ssh/authorized_keys. The ~/.ssh directory and the file itself must have strict permissions:

# on the server
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# if the directory or file does not exist, create them first

Any deviation (e.g., chmod 644) will cause the SSH daemon to reject the key because of the StrictModes setting.

Connecting Without a Password

When the client initiates a connection, the server sends a random challenge. The client signs it with the private key and sends the signature back. The server verifies the signature using the stored public key. If it matches, the session is authenticated and no password is requested.

Practical Configuration Example

1. Generate a Modern Key
2. Copy the Public Key to the Server
3. Verify the Setup
4. Disable Password Authentication (Optional)

1. Generate a Modern Key

# on the client
ssh-keygen -t ed25519 -C "${USER}@${HOST}" -f ~/.ssh/id_ed25519
# optionally set a passphrase to encrypt the private key

2. Copy the Public Key to the Server

The ssh-copy-id utility automates the copy and permission adjustments. Run it as the target user on the server:

# on the client
ssh-copy-id -i ~/.ssh/id_ed25519.pub ${USER}@${HOST}
# or, manually:
# cat ~/.ssh/id_ed25519.pub | ssh ${USER}@${HOST} "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Confirm that the public key now appears in ~/.ssh/authorized_keys on the server.

3. Verify the Setup

Attempt a connection:

# on the client
ssh -v ${USER}@${HOST}

The -v flag prints debug lines. Look for a line similar to:

debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/${USER}/.ssh/id_ed25519 RSA SHA256:...

After the handshake, you should see Authentication succeeded (publickey). If a passphrase was set, you will be prompted to enter it once per session.

4. Disable Password Authentication (Optional)

For maximum security, edit /etc/ssh/sshd_config on the server:

# on the server
PasswordAuthentication no
PubkeyAuthentication yes

Reload the daemon:

# on the server
sudo systemctl reload sshd

Now, any login attempt without a valid public key will be rejected.

Common Pitfalls and How to Avoid Them

• Incorrect Permissions – ~/.ssh must be 700, authorized_keys 600. Even a single stray chmod 644 will cause authentication to fail.
• Using Outdated Algorithms – ssh-rsa (SHA‑1) is deprecated in OpenSSH 9+. Prefer ed25519 or rsa-sha2-256/512.
• Passphrase Neglect – An empty passphrase leaves the private key readable if the client machine is compromised. Use a strong passphrase or consider an SSH agent with a timeout.
• Key Compromise – If a private key is stolen, any host that trusts the corresponding public key is compromised. Revoke the key by removing it from authorized_keys and, if necessary, generate a new pair.
• Wrong File Path – The default authorized_keys location is ~/.ssh/authorized_keys. If you change AuthorizedKeysFile in sshd_config, you must update the path accordingly.

When to Use a Password vs Key

Passwords remain useful for one‑time, low‑risk logins (e.g., a single‑use admin console). For routine remote work, key‑based authentication is superior: it is faster, less error‑prone, and resistant to brute‑force attacks. If you need a fallback, keep a strong password and enable PermitRootLogin prohibit-password in sshd_config to allow root logins only via key.

Summary

SSH public‑key authentication turns remote access into a cryptographic handshake that is both secure and convenient. By generating a modern key pair, copying the public key to authorized_keys with correct permissions, and optionally disabling password logins, you obtain a passwordless login that is resilient against guessing and phishing attacks. Always verify the authentication method with ssh -v and check server logs for any anomalies.