SSH Keys Explained: The Complete Guide to Secure Server Authentication

What Are SSH Keys?

SSH (Secure Shell) keys are a pair of cryptographic keys used to authenticate a client to a server without transmitting a password over the network. The pair consists of a private key (kept secret on your machine) and a public key (placed on the server you want to access). When you connect, the server uses the public key to create a challenge that only the holder of the corresponding private key can answer.

This is fundamentally more secure than password authentication because the private key never leaves your machine and never travels over the network. Even if an attacker intercepts the connection, they cannot derive the private key from the public key or the authentication exchange.

How SSH Key Authentication Works

The authentication flow follows these steps:

1. Connection initiation: You run ssh user@server. Your SSH client and the server perform a key exchange to establish an encrypted channel.
2. Public key offer: Your client offers one of your public keys to the server.
3. Challenge: The server checks if that public key exists in the user's ~/.ssh/authorized_keys file. If found, it encrypts a random challenge with the public key and sends it back.
4. Response: Your client decrypts the challenge using your private key and sends a hash of the result back to the server.
5. Verification: The server verifies the hash. If it matches, authentication succeeds. No password was transmitted.

SSH key authentication is not just more secure than passwords — it is also faster, automatable, and eliminates the risk of brute-force password attacks entirely.

Generating SSH Keys with ssh-keygen

The ssh-keygen command generates key pairs. In 2026, you should use Ed25519 keys as the default. They are faster, more secure, and produce shorter keys than RSA.

Ed25519 (Recommended)

ssh-keygen -t ed25519 -C "your_email@example.com"

This creates two files: ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). The -C flag adds a comment to help you identify the key later.

RSA (Legacy Compatibility)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Use RSA only when connecting to older systems that do not support Ed25519. Always use at least 4096 bits — 2048-bit RSA keys are considered the bare minimum and should be avoided for new deployments.

ECDSA

ssh-keygen -t ecdsa -b 521

ECDSA is another elliptic curve option, but Ed25519 is generally preferred because its implementation is simpler and less prone to side-channel attacks.

Passphrase Protection

When generating a key, ssh-keygen asks for a passphrase. Always set one. The passphrase encrypts the private key file on disk using AES-256. If someone copies your private key file, they still cannot use it without the passphrase.

A good passphrase is 4-6 random words (a diceware passphrase) or a long sentence you can remember. Use a password generator if you need ideas.

Deploying Your Public Key

Copy your public key to the remote server's ~/.ssh/authorized_keys file:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

If ssh-copy-id is not available, you can do it manually:

cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

The permissions are critical: ~/.ssh must be 700 and authorized_keys must be 600. OpenSSH refuses to use keys if permissions are too open. Use our chmod calculator to verify permission values.

SSH Config File

The ~/.ssh/config file eliminates the need to remember hostnames, usernames, ports, and key paths. Here is a practical example:

Host prod
    HostName 52.201.126.70
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 22
    ForwardAgent no

Host staging
    HostName 107.21.139.213
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Now you can just type ssh prod instead of the full command. This is not just convenient — it reduces errors and makes automation much simpler.

SSH Agent: Managing Keys in Memory

Typing your passphrase every time you connect is tedious. The ssh-agent caches your decrypted private key in memory for the duration of your session:

# Start the agent
eval "$(ssh-agent -s)"

# Add your key (prompts for passphrase once)
ssh-add ~/.ssh/id_ed25519

# List loaded keys
ssh-add -l

On macOS, you can add keys to the Keychain so they persist across reboots:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Agent Forwarding: Use With Caution

Agent forwarding (ssh -A) lets a remote server use your local SSH agent to authenticate to a third server. For example, if you SSH into a bastion host and then need to SSH to an internal server, agent forwarding lets the bastion use your local key without copying the key to the bastion.

Warning: Agent forwarding gives the remote server access to your SSH agent. If that server is compromised, an attacker could use your agent to authenticate to other servers. Only enable it for trusted hosts, and prefer ProxyJump instead:

# Safer alternative to agent forwarding
ssh -J bastion internal-server

# Or in ~/.ssh/config
Host internal
    HostName 10.0.1.50
    ProxyJump bastion

Security Best Practices

• Use Ed25519 for all new keys. It is faster, more secure, and produces 68-character public keys vs 400+ for RSA-4096.
• Always set a passphrase on your private key. Use ssh-agent to avoid retyping it.
• Disable password authentication on servers once SSH keys are configured: set PasswordAuthentication no in /etc/ssh/sshd_config.
• One key per device. Do not copy private keys between machines. Generate a new pair for each device.
• Rotate keys regularly. Generate new keys annually and remove old public keys from authorized_keys.
• Set correct permissions: chmod 700 ~/.ssh, chmod 600 ~/.ssh/id_*, chmod 644 ~/.ssh/*.pub, chmod 600 ~/.ssh/authorized_keys.
• Disable root login: Set PermitRootLogin no in sshd_config.
• Use AllowUsers or AllowGroups to restrict which accounts can log in via SSH.
• Never share private keys over email, Slack, or any messaging platform. If you need to share credentials, use a zero-knowledge encrypted paste.

Troubleshooting Common Issues

"Permission denied (publickey)"

This usually means one of three things: the public key is not in authorized_keys, the file permissions are wrong, or SSH is offering the wrong key. Debug with:

ssh -vvv user@server 2>&1 | grep -i "offering\|trying\|authentication"

"WARNING: UNPROTECTED PRIVATE KEY FILE!"

Your private key file has too-open permissions. Fix it:

chmod 600 ~/.ssh/id_ed25519

"Host key verification failed"

The server's host key changed (common after a server rebuild). Verify the change is legitimate, then remove the old key:

ssh-keygen -R server-hostname

SSH Keys for Git (GitHub, GitLab, Bitbucket)

All major Git hosting platforms support SSH key authentication. Once configured, you can push and pull without entering your password or personal access token:

# Test GitHub connectivity
ssh -T git@github.com

# Clone via SSH
git clone git@github.com:username/repo.git

Add your public key in your platform's settings: GitHub → Settings → SSH and GPG keys, GitLab → Preferences → SSH Keys.

The Bottom Line

SSH keys are non-negotiable for anyone who works with servers. They are more secure, more convenient, and more automatable than passwords. Generate an Ed25519 key pair today, protect it with a passphrase, disable password authentication on your servers, and never look back.

Need to share server credentials with your team? Do it securely with a zero-knowledge encrypted paste. Explore our developer tools including the password generator, hash generator, and chmod calculator.