ssh-keygen: Generate Secure SSH Keys and Manage Linux Server Access

What is ssh-keygen?

The ssh-keygen command generates, manages, and converts SSH authentication keys. SSH public key authentication is the strongly recommended alternative to password-based SSH login: a private key (kept on the administrator’s workstation and protected by a passphrase) is paired with a public key (placed in ~/.ssh/authorized_keys on the server). The server verifies the client’s possession of the private key during the authentication handshake without the key itself ever being transmitted over the network. The algorithm choice (Ed25519, RSA-4096, ECDSA) significantly affects both security level and key size. Ed25519 is the current recommended algorithm: faster, shorter keys, and equivalent or better security than RSA-4096.

Syntax

ssh-keygen -t ed25519 -C 'comment'
ssh-keygen -t rsa -b 4096 -C 'comment'
ssh-keygen -lf /path/to/key.pub
ssh-keygen -p -f ~/.ssh/id_ed25519
ssh-keygen -R hostname

-t specifies the algorithm type. -b specifies key size in bits (for RSA). -C adds a comment (usually email or hostname for identification). -lf shows the fingerprint of an existing public key. -p -f changes the passphrase of an existing key without regenerating it. -R removes a host entry from known_hosts.

Key Options and Flags

Common Use Cases

Generate and Deploy an Ed25519 Key Pair for a New Server

The complete workflow for setting up key-based authentication: generate the key pair on the workstation (never on the server), copy the public key to the server’s authorized_keys, verify the key authentication works, then disable password authentication in sshd_config.

# On your workstation:
ssh-keygen -t ed25519 -C "admin@company_$(date +%Y-%m)" -f ~/.ssh/id_ed25519_prodserver

# Copy public key to server
ssh-copy-id -i ~/.ssh/id_ed25519_prodserver.pub user@server

# Test key auth
ssh -i ~/.ssh/id_ed25519_prodserver user@server

# Only after confirming key auth works, disable passwords on server

Rotate SSH Keys After a Security Incident

After any suspected private key exposure — laptop theft, accidental key push to a repository, shared access revocation — the compromised public key must be removed from all authorized_keys files and replaced with a new key pair. This is more operationally complex than initial deployment, especially at scale.

# Generate new key pair
ssh-keygen -t ed25519 -C "admin@company_rotated_$(date +%Y-%m)" -f ~/.ssh/id_ed25519_new

# Add new key to server BEFORE removing old key
ssh-copy-id -i ~/.ssh/id_ed25519_new.pub user@server

# Verify new key works
ssh -i ~/.ssh/id_ed25519_new user@server

# Remove old/compromised key from authorized_keys
ssh user@server 'grep -v "compromised_key_fingerprint" ~/.ssh/authorized_keys > /tmp/auth_new && mv /tmp/auth_new ~/.ssh/authorized_keys'

Audit authorized_keys Files on a Server

Attackers who compromise a server often add their own public key to the root or admin user’s authorized_keys file for persistent SSH access. Regularly audit all authorized_keys files to verify they contain only expected keys. The comment field in each key line identifies the key’s claimed origin.

# Check all authorized_keys on the system
for user in $(awk -F: '$3>=1000{print $1}' /etc/passwd); do
  HOME_DIR=$(getent passwd $user | cut -d: -f6)
  AUTH_KEYS="$HOME_DIR/.ssh/authorized_keys"
  [ -f "$AUTH_KEYS" ] && echo "=== $user ==" && cat "$AUTH_KEYS"
done

# Also check root
cat /root/.ssh/authorized_keys 2>/dev/null

Security Relevance: Algorithm Choice and Key Protection

Practical Examples

Generate an Ed25519 key with a descriptive comment and verify the fingerprint

ssh-keygen -t ed25519 -C "admin@prodserver_2026-03" -f ~/.ssh/id_ed25519_prod

# Display fingerprint for out-of-band verification
ssh-keygen -lf ~/.ssh/id_ed25519_prod.pub

# Set correct permissions
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub

Generates an Ed25519 key pair with a date-stamped comment for auditability. The fingerprint is displayed using SHA256 format by default in recent OpenSSH versions — this is the format used by GitHub, GitLab, and cloud provider consoles for key verification. Verify the fingerprint matches what you see in the cloud console or server log.

Secure the authorized_keys file with correct permissions

# On the server — fix permissions if incorrect
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify
ls -la ~/.ssh/
ls -la ~/.ssh/authorized_keys

sshd rejects public keys from authorized_keys files with incorrect permissions. If SSH key authentication stops working unexpectedly, check these permissions first. The .ssh directory must be 700 (not readable by others), and authorized_keys must be 600 (owner read/write only).

List all public keys authorized for a user account with fingerprints

while IFS= read -r key; do
  echo "$key" | ssh-keygen -l -f - 2>/dev/null
done < ~/.ssh/authorized_keys

Iterates over each key in authorized_keys and displays its fingerprint and comment. This allows you to verify that only expected keys are authorized and identify any unknown keys by their comment field. Unknown keys with no recognizable comment are a high-priority security finding.

Troubleshooting Common Issues

Summary

SSH key authentication is the most important security improvement over password-based SSH — it eliminates the brute force attack vector entirely. Use Ed25519 for all new key generation, always set a passphrase, generate keys on the workstation (never the server), and maintain an audit of authorized_keys across all managed servers. Rotate keys after any suspected exposure and audit authorized_keys files regularly for unauthorized entries.

• Generate Ed25519 keys with ssh-keygen -t ed25519 — it provides stronger security with smaller keys than RSA
• Always set a passphrase — a passphrase-protected key requires both the key file and the passphrase to use
• Audit ~/.ssh/authorized_keys on all servers regularly — an unauthorized key is a confirmed persistent access backdoor