SSH Key Authentication

Passwords are secrets you type into a box, hoping nobody's watching. SSH keys are secrets that never leave your computer—and somehow still prove who you are.

That's not a minor improvement. It's a fundamentally different approach to authentication.

The Core Insight

Public key cryptography solves an impossible-sounding problem: how do you prove you have a secret without revealing the secret?

The answer involves mathematical one-way functions, but the practical result is simple. You generate two keys—a private key and a public key—that are mathematically linked. Data encrypted with one can only be decrypted with the other.

Your private key stays on your computer. You never send it anywhere. You never share it. If someone gets it, they can impersonate you.

Your public key goes everywhere. You can post it on your website, email it to strangers, install it on every server you access. It doesn't matter who has it. The public key can only verify that you possess the private key—it can't be used to derive the private key or impersonate you.

This asymmetry is the whole trick.

The Authentication Dance

When you connect to a server with SSH key authentication, here's what actually happens:

1. The server has your public key on file
2. The server generates a random challenge and encrypts it with your public key
3. Your computer receives this encrypted blob
4. Your computer decrypts it with your private key
5. Your computer sends proof that it decrypted correctly
6. The server verifies the proof and lets you in

Your private key never travels over the network. An attacker watching the connection sees encrypted challenges and responses—nothing they can use to impersonate you, nothing they can replay.

With passwords, you send the secret itself. With keys, you prove you have the secret without revealing it.

Generating Keys

The ssh-keygen command creates a key pair:

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

ED25519 keys are the modern standard—shorter, faster, and more secure than RSA. The -C flag adds a comment (your email) to identify the key later.

You'll be asked for a passphrase. This encrypts your private key on disk. If someone steals the key file, they still need the passphrase to use it. You'll enter this passphrase when you use the key, though SSH agents can remember it for you.

The process creates two files:

• ~/.ssh/id_ed25519 — your private key (guard this)
• ~/.ssh/id_ed25519.pub — your public key (share freely)

For older systems that don't support ED25519, use RSA with 4096 bits:

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

Installing Your Public Key

For key authentication to work, the server needs your public key. The easiest way:

ssh-copy-id username@server

This connects with your password (one last time), copies your public key to the server's ~/.ssh/authorized_keys file, and sets the right permissions. After this, you authenticate with your key.

If ssh-copy-id isn't available, copy the key manually. View your public key:

cat ~/.ssh/id_ed25519.pub

This shows a single line starting with ssh-ed25519. Copy it, connect to the server with your password, and add it:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-key-here..." >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The permissions matter. SSH refuses to use authorized_keys files that others can read.

Managing Multiple Keys

You might want separate keys for work, personal projects, and automated systems. Generate them with different names:

ssh-keygen -t ed25519 -f ~/.ssh/id_work
ssh-keygen -t ed25519 -f ~/.ssh/id_personal

Specify which key to use with -i:

ssh -i ~/.ssh/id_work username@work-server

But that gets tedious. The SSH config file (~/.ssh/config) is better:

Host work
    HostName 192.168.1.10
    User admin
    IdentityFile ~/.ssh/id_work

Host personal
    HostName example.com
    User me
    IdentityFile ~/.ssh/id_personal

Now ssh work and ssh personal use the right key, hostname, and username automatically.

SSH Agents

Entering your passphrase every time defeats the convenience of keys. SSH agents solve this.

An agent runs in the background, holding decrypted private keys in memory. When SSH needs to authenticate, it asks the agent. You enter your passphrase once per session.

Add a key to the agent:

ssh-add ~/.ssh/id_ed25519

On macOS, configure SSH to use the system keychain:

Host *
    AddKeysToAgent yes
    UseKeychain yes

Jumping Through Servers

Sometimes you need to connect through an intermediate server. Agent forwarding lets your local keys authenticate on subsequent hops:

ssh -A username@jump-server

From jump-server, you can SSH to other servers using your local keys.

But there's a risk: anyone with root access on the jump server can hijack your forwarded agent while you're connected. A safer alternative is ProxyJump:

ssh -J jump-server final-server

This creates a direct encrypted tunnel through the jump server without exposing your agent.

Revoking Access

This is where keys shine over passwords.

To revoke access, remove the public key from ~/.ssh/authorized_keys on the server. That's it. The corresponding private key—wherever it is—can no longer authenticate.

Each key is unique. You can give different keys to different people or systems. When someone leaves or a key is compromised, you remove only that key. Other access continues unaffected.

With passwords, revocation means changing the shared secret and distributing the new one. With keys, it's surgical.

Security Practices

Use passphrases. A stolen key file is useless without the passphrase.

Lock down permissions:

chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

SSH refuses keys with loose permissions.

Never copy private keys to servers. Use agent forwarding or ProxyJump instead.

Rotate keys periodically. Generate new ones every year or two.

Disable password authentication once keys work. Edit /etc/ssh/sshd_config:

PasswordAuthentication no

This eliminates password-based attacks entirely.

Keys for Automation

Scripts and deployment systems can't enter passphrases. Generate dedicated keys without passphrases for automation, but treat them as secrets—restrict access, document their purpose, and install them only where needed.

Configuration management tools (Ansible, Puppet, Chef), CI/CD systems, and monitoring all rely on SSH keys. The alternative—embedding passwords in scripts—is far worse.

Scaling Up

Large organizations use additional tools:

Configuration management distributes public keys automatically to all servers.

Bastion hosts centralize access—all connections go through one hardened server.

SSH certificates let a Certificate Authority sign keys with expiration dates, providing central control without managing individual keys on every server.

Directory integration ties SSH access to LDAP or Active Directory groups.

But the principle stays the same: possession of a private key proves identity, and removing a public key revokes access.