What are SSH Keys

SSH keys are asymmetric cryptographic key pairs used for authentication to SSH (Secure Shell) servers. The private key stays on the user’s machine and is never transmitted. The public key is placed on the server in the ~/.ssh/authorized_keys file. During authentication, the server sends a challenge that only the holder of the matching private key can answer — proving identity without transmitting a password or secret over the network.

Why it matters

• Eliminates password attacks — SSH key authentication is immune to brute force, credential stuffing, and phishing. There’s no password to guess or steal from the network.
• Automation enabler — scripts, CI/CD pipelines, and automated systems can authenticate to servers without storing passwords. The private key file is the credential.
• Stronger than passwords — an Ed25519 key provides 128-bit security. Even the strongest password provides far less entropy. Key-based auth is cryptographically stronger by orders of magnitude.
• Scale problem — every user-server relationship creates a public key entry. 100 users × 50 servers = 5,000 authorized_keys entries to manage. Without tooling, this becomes unmanageable.
• Audit requirement — compliance frameworks (SOC 2, ISO 27001, PCI DSS) require access control documentation. Unmanaged SSH keys are undocumented access paths that auditors flag.

How it works

1. Key generation — user generates a key pair on their local machine (ssh-keygen). Private key saved to ~/.ssh/id_ed25519, public key to ~/.ssh/id_ed25519.pub.
2. Public key deployment — the public key is added to ~/.ssh/authorized_keys on the target server (manually, via ssh-copy-id, or through configuration management).
3. Connection initiation — client connects to server on port 22. Server presents its host key (server authentication).
4. Authentication challenge — server generates a random challenge, encrypts it with the user’s public key from authorized_keys.
5. Client proves identity — client decrypts the challenge with its private key and responds. Only the correct private key can produce the right answer.
6. Session established — authentication succeeds, encrypted session begins.

In real systems

Generating SSH keys:

# Ed25519 (recommended — fast, secure, small keys)
ssh-keygen -t ed25519 -C "user@example.com"
# Produces: ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public)

# RSA 4096 (legacy compatibility)
ssh-keygen -t rsa -b 4096 -C "user@example.com"

# With passphrase (encrypts private key at rest)
ssh-keygen -t ed25519 -C "user@example.com" -N "strong-passphrase"

Deploying public key to server:

# Automated deployment
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.com

# Manual (append to authorized_keys)
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# Configuration management (Ansible)
- name: Deploy SSH key
  authorized_key:
    user: deploy
    key: "{{ lookup('file', 'keys/deploy_ed25519.pub') }}"
    state: present

SSH config for multiple keys:

# ~/.ssh/config
Host production-*
  IdentityFile ~/.ssh/id_ed25519_prod
  User deploy

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

Disabling password authentication (hardening):

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Where it breaks

Private key without passphrase on shared system — a developer generates a key without a passphrase for convenience. The private key file (id_ed25519) is readable by anyone with access to their home directory. If the machine is compromised, the attacker has immediate access to every server that trusts that key — no cracking required. Always use a passphrase and ssh-agent for convenience without sacrificing security.

Orphaned authorized_keys entries — an employee leaves the company. Their public key remains in authorized_keys on 30 servers because there’s no centralized key management. The former employee (or anyone who obtains their private key) retains access indefinitely. Without a process to remove keys when access should be revoked, SSH keys become permanent backdoors.

Key sprawl — over 5 years, a team of 20 engineers has generated multiple keys each, deployed to various servers, with no inventory. An audit reveals 2,000 authorized_keys entries across the infrastructure, but only 15 engineers are currently active. Nobody knows which keys are still needed. The cleanup effort is massive because removing the wrong key breaks automation. This is why SSH certificates (with expiry) are replacing static keys in mature organizations.

Operational insight

The fundamental problem with SSH keys isn’t cryptographic — it’s lifecycle. SSH keys have no expiry date. Once a public key is in authorized_keys, it grants access forever until someone manually removes it. Compare this to TLS certificates (which expire and force renewal) or passwords (which can be expired by policy). SSH keys are the only common authentication credential with no built-in expiry mechanism. This is why organizations with mature security programs are migrating to SSH certificates (which have validity periods) or integrating SSH with identity providers (Teleport, Smallstep) that issue short-lived credentials tied to SSO sessions.

Related topics

• SSH Key Authentication
• SSH Key Rotation
• SSH Certificate-based Authentication
• What is Asymmetric Encryption
• Key Lifecycle Management