SSH Keys: How They Actually Work (And Why Passwords Aren't Enough)

Every time you push to GitHub without typing a password, an SSH key pair is doing the work. It's one of the most common tools in a developer's day that almost nobody stops to understand.

Two keys, one job

An SSH key pair is two mathematically linked files: a private key you keep secret on your machine, and a public key you hand out freely — to GitHub, a server, anywhere you want to log in. Anything encrypted with the public key can only be decrypted with the matching private key, and that one-way relationship is the entire trick.

What actually happens when you connect

When you run ssh user@server, the server doesn't ask for your private key — it never sees it. Instead it encrypts a random challenge with your public key and asks your machine to prove it can decrypt it. Your SSH client does that locally with your private key and sends back proof. No password, and no secret ever crosses the network.

Generating your own pair

One command creates both files:

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

This writes id_ed25519 (private — never share this) and id_ed25519.pub (public — safe to paste anywhere) into ~/.ssh/. Ed25519 is the modern default; you'll still see older RSA keys around, but there's no reason to generate new ones that way.

Why this beats a password

A password can be guessed, phished, or reused across sites. A private key is never transmitted, never typed into a login form, and effectively impossible to brute-force at the lengths SSH uses. That's why most platforms — GitHub, GitLab, most cloud servers — treat an SSH key as the baseline for any serious account.