Banish the Password
Typing a password every time you connect to a remote server is slow, error-prone, and insecure — passwords can be intercepted, guessed, or leaked. SSH key authentication replaces the password with a cryptographic proof of identity that cannot be replayed or brute-forced.
How it works — the key pair
SSH uses asymmetric cryptography. You generate a mathematically linked pair of keys:
- Private key (
~/.ssh/id_ed25519): Lives only on your machine. Never leaves it. Never gets shared. This is your identity. - Public key (
~/.ssh/id_ed25519.pub): Placed on any server you want to access, in the file~/.ssh/authorized_keys. It is safe to share — it is mathematically useless without the private key.
Think of it like a padlock you hand to the server. Only your private key can open it. The server locks a challenge with your public key; if your machine can unlock it, you are authenticated — no password ever crosses the network.
Generating and installing a key pair
The workflow has three logical steps, independent of the exact tooling used: generate a key pair, copy the resulting public key onto every server you want to access — appending it to that server's list of trusted public keys — and from then on, authenticating is just connecting; the handshake happens automatically with no password prompt. Key generation typically also asks for a passphrase, which encrypts the private key at rest on your own disk — a second layer of protection if the key file itself is ever stolen off your laptop.
Why ed25519 over rsa
ed25519 uses elliptic curve cryptography rather than RSA's large-prime-based math, producing shorter keys that are faster to verify and considered more secure than an RSA-2048 key of much greater size. It's the right default for new keys; RSA at a larger key size remains an acceptable fallback on older systems that don't support elliptic curve keys.
Permissions are enforced by SSH
SSH is deliberately paranoid about file permissions, because a private key readable by anyone other than its owner defeats the entire security model — it stops being proof of a single person's identity. If a key's directory or file permissions are too permissive, SSH refuses to use that key at all rather than silently accepting a weakened guarantee, surfacing a clear warning until ownership and permissions are locked down to the owner alone.
The SSH config file
For servers you connect to regularly, ~/.ssh/config lets you define a short alias that expands to the full connection details — hostname, username, which key to use, which port. Once defined, connecting is just the alias instead of retyping the full address, username, and key path every time. This is more than convenience: centralizing per-host settings in one file means you don't have to remember which of a dozen servers uses a nonstandard port or a different login user.
Interviewers often ask: "How does SSH key authentication work?" A weak answer names the files. A strong answer explains the cryptographic handshake: the server encrypts a random challenge with your public key; your SSH client decrypts it with your private key and sends back a hash of the decrypted value; the server verifies the hash. Your private key never leaves your machine — only the proof that you possess it does. Follow up by mentioning that ed25519 is preferred over RSA for new keys, and that the passphrase on the private key provides a second layer of protection if the key file is ever stolen.