SSH Keys Explained: Public vs Private Key (Simple Guide)

If you work with WordPress, servers or Git, you use SSH keys almost every day. You run git push, connect to a client's VPS, or deploy a plugin from GitHub Actions, and it just works. But if someone asked you why it works, and why there are two keys instead of one, could you explain it?

Let's fix that. In this post I will explain what SSH keys are, how the authentication really happens, and which good habits will keep your servers and repositories safe.

What is an SSH key pair?

When you run ssh-keygen, your computer does not create one key. It creates a pair of keys that are mathematically linked:

The private key (for example id_ed25519). It stays on your machine. It is your identity.
The public key (for example id_ed25519.pub). You can share it with anyone, post it online, or paste it into a hundred servers.

This is called asymmetric cryptography. The important property is simple: something signed with the private key can be verified with the public key, but you cannot work backwards and calculate the private key from the public one.

A good analogy is a padlock and its key. The public key is the open padlock: you can hand copies to everybody, and they can install it wherever they want. The private key is the only key that opens it, and you never give it away.

A common misunderstanding: you don't connect with the public key

Many people say "I use my public key to connect". It is a natural way to put it, because you copy the public key into GitHub or into a server. But the roles are these:

The public key is installed on the server. It tells the server "this person is allowed in".
The private key is used by you, on your computer, to prove that you are that person.

The server holds the padlock. You hold the only key that opens it.

How SSH authentication works, step by step

Imagine you run this command:

ssh david@my-server.com

This is what happens behind the scenes:

Your SSH client tells the server: "I am david, and I have this public key."
The server looks in ~/.ssh/authorized_keys for that public key. If it is not there, access is denied.
If it is there, the server sends a challenge: a piece of random data that is unique to this connection.
Your client signs that data with your private key and sends back the signature.
The server checks the signature using the public key. If it matches, you are in.

Notice what never happens: your private key never travels over the network. Only a signature does, and that signature is only valid for that one session, so nobody can record it and replay it later.

Why two keys are better than a password

With a password, the secret has to be shared: you know it and the server knows it (or at least a hash of it). If the server leaks, or someone intercepts your login, the secret is exposed.

With a key pair, the secret lives in one single place, your computer. The servers only store public keys, which are harmless on their own. If an attacker steals the whole authorized_keys file, they get nothing they can use to impersonate you.

It also scales much better. If you manage 30 client servers, you do not need 30 passwords. You put the same public key on all of them. And when a team member leaves, you remove their line from authorized_keys and that's it, with no password rotation.

The other pair of keys: the server's identity

There is a second, less known part. The server also has its own key pair. The first time you connect, you see something like this:

The authenticity of host 'my-server.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no)?

That message is the server showing you its public key fingerprint, so you can check that you are talking to the real server and not to an impostor. When you accept, the key is saved in ~/.ssh/known_hosts. Next time, if the key changes, SSH warns you loudly.

So authentication goes in both directions: the server verifies who you are with your key, and you verify who the server is with its key.

Real-life examples

GitHub: you paste your .pub file in Settings → SSH and GPG keys. From then on, every git push is signed with your private key.
Deployments with GitHub Actions: you create a dedicated key pair just for deploying. The public key goes to the server (or as a deploy key in the repository), and the private key is stored as an encrypted secret. If it ever leaks, you revoke only that one.
Client servers: your public key lives in each server's authorized_keys. One identity, many servers, no shared passwords.

How to generate a key pair

Today the recommended algorithm is Ed25519. It is faster and shorter than classic RSA, and very secure:

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

SSH will ask where to save it (the default ~/.ssh/id_ed25519 is fine) and for a passphrase. Then you can copy the public key to a server with:

ssh-copy-id david@my-server.com

Or print it and paste it where you need it, for example in GitHub:

cat ~/.ssh/id_ed25519.pub

Good habits to keep your keys safe

Use a passphrase. If someone steals your laptop, the private key file alone is useless. With ssh-agent or your system keychain you only type it once per session.
Never share the private key. Not in Slack, not in an email, not in a Git repository, not inside a Docker image. If you think it was exposed, generate a new pair and remove the old public key everywhere.
One key per device. Do not copy the same private key between computers. If you lose one device, you revoke just that key.
Use dedicated keys for automation. CI/CD pipelines should have their own keys with the minimum permissions they need.
Review authorized_keys from time to time. Remove keys of people or machines that no longer need access.

Quick summary

An SSH key pair is a public key you can give to anyone and a private key you keep to yourself. The server stores the public one, you prove your identity by signing a challenge with the private one, and the secret never leaves your computer. That is why SSH keys are safer than passwords, easier to manage across many servers, and the standard way to work with Git and remote machines.

Next time you run git push, you will know exactly what is happening behind the scenes.