How SSH Key Authentication Works
SSH key authentication replaces passwords with asymmetric cryptography. You generate a key pair: a private key that stays on your machine and a public key that you copy to the server. When you connect, the server issues a challenge encrypted with your public key. Only the holder of the private key can decrypt it, proving identity without transmitting a password.
This is more secure than passwords in several ways: there is nothing to brute-force over the network, phishing can't steal a key the same way it steals a password, and you can revoke access by removing the public key from the server without changing credentials everywhere.
RSA vs ECDSA vs Ed25519
RSA is the oldest and most widely supported algorithm. A 2048-bit RSA key is considered secure for most purposes, and 4096-bit keys are used where extra margin is needed. RSA keys are larger and slower to generate and verify than modern alternatives.
ECDSA (Elliptic Curve Digital Signature Algorithm) offers equivalent security to RSA with much shorter keys. A 256-bit ECDSA key provides security comparable to a 3072-bit RSA key. The NIST P-256 and P-384 curves are the most commonly used.
Ed25519 is a modern Edwards-curve algorithm designed for speed and security. It is resistant to certain side-channel attacks that affect some ECDSA implementations and is now the recommended algorithm for new SSH keys when supported by the server.
For new keys, prefer Ed25519 if your infrastructure supports it, ECDSA 256 otherwise. Use RSA only when legacy compatibility is required.
Key Length and Security
For RSA, 2048 bits is the current minimum recommendation from NIST, with 3072 or 4096 bits preferred for keys that need to remain secure for many years. For ECDSA and Ed25519, the curve choice determines security — curve selection matters more than bit length.
Protecting Your Private Key with a Passphrase
A passphrase encrypts the private key file on disk. Without a passphrase, anyone who copies the private key file gains full access to everything that key unlocks. With a passphrase, they also need to know the passphrase. For production servers, CI/CD systems that use SSH deploy keys, and personal GitHub access, always use a passphrase.
ssh-agent caches the decrypted key in memory so you only enter the passphrase once per session, eliminating the friction of re-entering it on every connection.
Where to Store Keys
Private keys belong in ~/.ssh/ with permissions 600 (owner read/write only). The public key goes in ~/.ssh/authorized_keys on the server, one key per line. Never check a private key into version control. If a private key is accidentally committed, treat it as compromised and generate a new key pair immediately — rotating out the old public key from every server it was deployed to.
Generating Keys Securely
The gold standard is generating keys on the machine where they will be used, using ssh-keygen in a terminal. Browser-based generators that use the Web Crypto API are a reasonable alternative for scenarios where you need a quick key pair without terminal access — the key material is generated locally using the browser's cryptographic primitives and never transmitted to any server. The DevHexLab SSH Key Generator works this way.
Avoid any tool that generates keys server-side and sends them to you over the network, even over HTTPS. Once a private key leaves the device where it was created, you can never be fully certain of its confidentiality.
Deploying Public Keys
On Linux servers, append the public key to ~/.ssh/authorized_keys. On GitHub and GitLab, paste the public key in the SSH Keys section of your account settings. For cloud providers like AWS, upload the public key to create a key pair resource and reference it when launching instances.
After deploying a new key, test the connection before closing the existing session to avoid locking yourself out.