How SSH key authentication works.
Public-key auth feels like magic — you put a file on a server and suddenly you can log in without a password. Underneath, it's a six-step handshake that proves you hold a secret without ever sending it across the wire.
How SSH key authentication works. Animated six-step handshake showing public/private key roles, challenge-response, signature verification, and channel establishment. Covers RHCSA EX200 security objectives.What actually happens between your laptop and the server when you type ssh user@host. Six steps that prove you hold a secret without sending it.
- ·Comfort with running ssh from a terminal at least once
- ·A rough sense that some encryption uses one key, some uses two
- ·Helpful: the SSH Key Setup tool on this site, if you haven't generated a key yet
Predict every message that crosses the wire during a key-auth login. Explain why the public key is safe to share and the private key isn't.
pace: 10 minutes
// arrows numbered to match lesson steps · steps 1 & 4 happen locally on each side, so only steps 2, 3, 5 and 6 appear as arrows crossing the wire.
Two halves of a math pair
An SSH key is two matching files. The private one stays on your laptop — keep it secret. The public one is safe to share, so you copy it onto every server you want to log in to. Anyone with the public key can CHECK a signature, but only the private key can MAKE one. That's the whole trick.
The private key never crosses the network. Not even once. The whole protocol is designed around proving possession of the private key by signing something a watcher can't replay — which is why pasting your private key into a chat or an email is a wipe-the-key incident, while pasting the public key is fine.
$ssh-keygen -t ed25519$ssh-keygen -t ed25519 -C label$ssh-copy-id user@host$ssh-add ~/.ssh/id_ed25519$ssh-add -l$ssh-add -D$ssh -v user@host$ssh-keygen -lf KEY$~/.ssh/id_ed25519$~/.ssh/id_ed25519.pub$~/.ssh/authorized_keys$~/.ssh/known_hosts$chmod 700 ~/.ssh$chmod 600 ~/.ssh/id_ed25519$/etc/ssh/sshd_config$PasswordAuthentication noWhy is it safe to paste your public key into a GitHub profile or send it in plaintext email?
Which file holds the PRIVATE key on your laptop?
Bob copies your ~/.ssh/authorized_keys file from the server to his laptop. Can he now log in as you?
What does ssh-agent do?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
SSH Key Setup tool
Step-by-step walk-through for generating your first key with ssh-keygen, copying the public half to a server with ssh-copy-id, and configuring ~/.ssh/config so you never type the full host again.
Read this lesson as text6 chapters · quiz answers
01Two halves of a math pair
An SSH key is two matching files. The private one stays on your laptop — keep it secret. The public one is safe to share, so you copy it onto every server you want to log in to. Anyone with the public key can CHECK a signature, but only the private key can MAKE one. That's the whole trick.
02Client offers a public key
Your laptop says hi to the server and shows it your public key — just the public half, never the private one. It's basically asking: 'do you recognize this key for the user alice?'
03Server picks a random challenge
The server checks if that public key is on its allowed list (the authorized_keys file). If yes, it makes up a random string and sends it back — essentially saying 'prove it's really you: sign this'.
04Client signs with the private key
Your laptop signs the random string using the private key. This happens entirely on your machine — the private key never touches the network. If you set a passphrase, ssh-agent remembers it so you don't retype every time.
05Signature crosses the wire, server verifies
The signature gets sent to the server. The server uses your public key (which it already has) to check whether the signature is genuine. If it is, you must be holding the matching private key — you're in.
06Authenticated — encrypted session opens
Login done. You get a shell, and from now on everything goes back and forth over an encrypted channel. The whole key dance only happens at login — disconnect and reconnect, and it runs again.
Quiz — answers
- Why is it safe to paste your public key into a GitHub profile or send it in plaintext email?
- →Because the math is one-way — you can verify signatures with a public key but you can't produce one without the private key.The public key reveals nothing useful to an attacker. Even if everyone in the world has it, only the holder of the matching private key can produce a valid signature. That's the entire point of asymmetric cryptography.
- Which file holds the PRIVATE key on your laptop?
- →~/.ssh/id_ed25519 (no .pub extension)The file without .pub is the private half. The .pub file is the public half, safe to share. authorized_keys holds public keys for users allowed in on the server side. known_hosts records which SERVER public keys you've previously trusted.
- Bob copies your ~/.ssh/authorized_keys file from the server to his laptop. Can he now log in as you?
- →No — that file contains only your public keys, which can verify signatures but cannot create them.authorized_keys is a list of public keys. Public keys verify; they don't sign. Bob would need YOUR PRIVATE key (from your laptop's ~/.ssh/id_ed25519) to log in as you — which is why that file must stay secret and unreadable to other users.
- What does ssh-agent do?
- →It stores your private key (decrypted via your passphrase) in memory and signs challenges on your behalf, so you don't retype the passphrase on every connection.The agent is a long-running process that holds unlocked private keys in memory. You enter your passphrase once (via
ssh-add), and from then on the agent handles signing for any ssh/scp/git command in your session — perfectly transparent.
keep going — these pair well with what you just learned.
SELinux booleans
Runtime on/off switches that toggle whole chunks of policy — getsebool, setsebool -P, finding the right one, and the denial-fixing workflow. RHCSA-ready.
TLS handshake, deep
Open every TLS 1.3 message — ClientHello, ServerHello, Certificate, CertificateVerify, Finished. Cipher suites, HKDF key derivation, SNI, ALPN, and why TLS 1.3 has built-in perfect forward secrecy.