How SSH Works: Key Exchange, Host Keys, and Public-Key Auth

SSH is the tool that lets an administrator sit at one machine and control another safely across an untrusted network. It replaced older tools like Telnet, which sent everything, including passwords, in plain readable text. Anyone on the path could watch a Telnet session and harvest credentials. SSH, the Secure Shell, wraps the whole remote session in encryption and adds strong ways to prove who is connecting. Understanding how it does that makes the difference between using SSH and using it well.

At heart SSH does two jobs in sequence. First it builds an encrypted channel and confirms which server you reached. Then, inside that channel, it proves who you are to the server. Keeping those two stages separate is the key to understanding the fingerprint warnings and the choice between passwords and keys.

Stage one: building the encrypted channel

When your client connects to an SSH server on TCP port 22, the two sides negotiate before any login happens. They agree on which encryption and integrity algorithms to use, then run a key exchange.

The key exchange is a Diffie-Hellman exchange. Both sides contribute a value, combine them, and each independently arrives at the same shared secret. The clever property is that this shared secret is never transmitted. Someone recording every packet of the exchange still cannot compute the key from what they saw. For the mechanics of that trick, see How Diffie-Hellman Works. From that shared secret both sides derive the symmetric keys that encrypt the rest of the session.

At this point the channel is encrypted, but encryption alone does not tell you who you are talking to. That is the job of the host key.

Stage two: the host key and trust on first use

Every SSH server has a host key, a long-term key pair that identifies the machine. During the key exchange, the server signs part of the exchange with its host private key. Your client checks that signature against the server's host public key. A valid signature proves the server holds the matching private key, which proves it is the machine that owns that host key rather than an impostor sitting in the middle.

The problem is knowing the correct host key in advance. The first time you connect, your client has nothing to compare against, so it shows you the key's fingerprint and asks whether to trust it:

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

This is trust on first use. If you accept, your client stores that fingerprint in its known_hosts file. On every later connection it checks the presented host key against the stored one. If they match, it connects silently. If they differ, it stops with a loud warning.

For fleets of servers, trust on first use scales poorly. Larger environments distribute known host keys ahead of time or use an SSH certificate authority that signs host keys, so clients trust any host the CA vouches for without prompting.

Stage three: proving who you are

Now the channel is encrypted and the server is verified. The server still needs to know that you are an authorized user. SSH supports several authentication methods, and two dominate.

Password authentication sends your password through the encrypted channel to the server, which checks it. It is simple and needs nothing set up in advance. It also inherits every weakness of passwords: they can be guessed, brute-forced, reused, and phished, and every login sends the secret itself to the server.

Public-key authentication works differently and better. You generate a key pair. The private key stays on your machine, protected by a passphrase. The public key is placed on the server in your account's authorized_keys file. When you log in:

1. The server sends a challenge, a random piece of data.
2. Your client signs the challenge with your private key.
3. The server verifies the signature with your public key.

A valid signature proves you hold the private key, without the private key ever leaving your machine. Nothing secret crosses the network. There is no password for a phishing page to capture and nothing on the server to steal that would let someone impersonate you elsewhere.

The asymmetry is worth dwelling on. With a password, the server has to hold something that can verify your secret, and every login puts the secret itself on the wire and briefly in the server's memory. Compromise the server and you may harvest passwords that users reused elsewhere. With public-key auth, the server only ever holds your public key, which is safe to publish. It cannot be used to log in as you, and stealing it teaches an attacker nothing useful. The private half stays on your device the whole time. That is the structural reason keys are safer, beyond simply being longer than a typical password.

The difference is not subtle. Password logins are the single most attacked door on the internet, and any server exposing SSH with passwords enabled will see constant automated guessing.

What SSH gives you beyond a shell

The same encrypted, authenticated channel powers more than an interactive terminal:

• Secure file transfer with SCP and SFTP, which move files over the SSH channel.
• Port forwarding and tunneling, which carry other protocols safely through the SSH connection.
• Remote command execution for automation and scripts.

All of it rides on the two-stage foundation: encrypt and verify the server, then authenticate the user. SSH runs on port 22 by default, which is worth knowing when you review what a machine exposes. See Common Ports Reference.

It helps to see how the two stages divide the work, because the guarantees are different and people often blur them together.

The first stage protects you from talking to an impostor and from anyone reading the session. The second protects the server from letting in someone who is not authorized. Both must succeed before a shell opens. A common mistake is assuming a working, encrypted connection means the server is trustworthy. Encryption and server verification are what the host key delivers; whether the machine itself is honestly run is a separate question the protocol cannot answer for you.

How to secure it

Setting up SSH correctly from the start avoids the most common exposures:

1. Use public-key authentication and disable passwords. This removes brute-force guessing as an attack path entirely. It is the highest-value single change.
2. Protect every private key with a passphrase. A key file without one is a plaintext credential the moment it is copied.
3. Verify host key fingerprints out of band. On first connection, confirm the fingerprint from a trusted source rather than accepting blindly, so trust on first use starts from a known-good value.
4. Keep the SSH software current. Run supported versions and use modern algorithms so weak ciphers and known flaws are not in play.
5. Go further with a full hardening pass. Disabling root login, restricting who can connect, and adding a bastion host all build on these basics. See the SSH Hardening Guide.

A walkthrough: what happens when you type ssh

Trace a single connection from the moment you run ssh [email protected] to the moment a shell opens. Seeing the order of events makes the two stages concrete and explains why each warning appears where it does.

1. TCP connection. Your client opens a TCP connection to the server on port 22. Nothing is encrypted yet; this is only the transport.
2. Version exchange. Both sides send a banner announcing their SSH protocol version and software. This lets each side know what the other supports before any cryptography starts.
3. Algorithm negotiation. The client and server each send a list of the key-exchange methods, ciphers, message-authentication algorithms, and compression they support, in preference order. They settle on the best method both share. If they share nothing acceptable, the connection fails here, which is what you see when a client refuses a server for offering only weak algorithms.
4. Key exchange. The two sides run the negotiated Diffie-Hellman exchange, each contributing a value and independently arriving at the same shared secret without that secret ever crossing the network. As part of this step the server signs a hash of the exchange with its host private key.
5. Host key check. Your client verifies that signature against the server's host public key, then compares the key against its known_hosts file. A first-time key prompts the fingerprint question. A matching key proceeds silently. A changed key stops with a loud warning.
6. Session keys derived. From the shared secret both sides derive the symmetric keys and integrity keys that protect every packet from here on. The channel is now encrypted and integrity-protected.
7. User authentication. Inside that protected channel, the server asks who you are. Your client offers a method, public-key or password, and proves your identity. Only after this succeeds does the server open a session.
8. Session. A shell, a file-transfer subsystem, or a forwarded port starts over the established channel.

The important thing to notice is the ordering. Encryption and server verification happen in steps 4 through 6, before you ever prove who you are in step 7. That is why a man-in-the-middle is caught by the host key check, well before any credential is offered, and why a changed host key must stop you before you type a password into a machine you have not verified.

Detection signals and what to watch

SSH is one of the most probed services on the internet, so knowing the signals of trouble is part of running it. Concrete indicators worth monitoring:

• A host key mismatch warning. The single most important client-side signal. It means the key presented does not match the one you stored. It can be a legitimate rebuild, or it can be interception. Confirm the real fingerprint out of band before accepting.
• High volumes of failed password logins. A server exposing password authentication will see constant automated guessing against common usernames. A spike, or a steady stream from many source addresses, is the background noise of brute-force attempts and a strong argument for disabling passwords entirely.
• Successful login from an unexpected source or at an unexpected time. Correlate accepted logins against where and when your users actually connect. An accepted public-key login from an unfamiliar network deserves a look, because it can mean a private key was copied.
• New or unexpected entries in authorized_keys. An attacker who gains access often adds their own public key to maintain it. Treat any authorized_keys change you did not make as a serious finding. This maps to the persistence behavior catalogued in MITRE ATT&CK under technique T1098.004, SSH authorized_keys modification.
• Unexpected port forwards or tunnels. SSH can carry other protocols. A session opening forwards you did not initiate can indicate the channel is being used to pivot deeper into the network.
• Logins using a key you thought was retired. If an old key still works, it was never removed from authorized_keys. Stale keys are a common quiet exposure.

How SSH compares to what came before

SSH replaced a family of tools that sent everything in the clear, and the contrast explains what each of its guarantees buys you.

The older tools failed on two fronts at once: anyone on the path could read the session, and there was no reliable way to confirm the server was genuine. SSH fixes both with the encrypted channel and the host key. Moving from password to public-key authentication then removes the last secret from the wire, so even the server no longer receives a reusable credential. Each row down the table removes one more thing an attacker on the network could steal.

Common mistakes

Pasting past a host key warning. The warning exists to make interception visible. Dismissing it out of habit throws away the exact protection the host key provides. Confirm the fingerprint through a trusted channel first.

Leaving password authentication enabled. Even with strong passwords, an exposed SSH server with passwords on will face endless automated guessing. Public-key authentication with passwords disabled removes that attack path entirely.

Generating a key without a passphrase. A private key with no passphrase is a plaintext credential the instant the file is copied. Always set a passphrase and use an agent so you type it once per session.

Copying a private key onto a shared machine. The private key should live in as few places as possible, ideally only on your own device. The public key can go anywhere; the private half should go almost nowhere.

Never removing old keys. Authorized_keys grows over time as people and systems come and go. A key that is never removed is a door that never closes. Audit authorized_keys periodically and remove keys for people and systems that no longer need access.

Assuming an encrypted connection means a trustworthy machine. The host key proves you reached the real server and the channel is private. Whether that machine is honestly run and free of compromise is a separate question the protocol cannot answer.

Frequently asked questions

What is the difference between the host key and my user key? The host key identifies the server. Every SSH server has one, and it is what your client checks to confirm it reached the real machine rather than an impostor. Your user key identifies you to the server during authentication. The host key answers "is this the right server?" and your user key answers "are you an allowed user?" They are different key pairs used in different stages.

What does the fingerprint warning on first connection mean? On a first connection your client has no stored host key to compare against, so it shows the key's fingerprint and asks you to confirm it. This is trust on first use. If you accept, the fingerprint is saved to known_hosts and checked on every later connection. You should confirm that first fingerprint from a trusted source rather than accepting blindly, so trust starts from a known-good value.

Why is public-key authentication safer than a password? With a password, the secret itself travels to the server on every login and briefly sits in the server's memory, and users often reuse it elsewhere. With public-key authentication the server holds only your public key, which is safe to publish, and each login proves you hold the private key by signing a challenge. Nothing secret crosses the network, so there is nothing for a phishing page to capture or an attacker to replay.

Should I change the default SSH port from 22? Moving off port 22 reduces automated background scanning noise, which can make logs quieter, and it is a minor obscurity measure. It is not a security control on its own, because a determined attacker scans all ports. Treat a non-standard port as log hygiene layered on top of the real controls: public-key authentication, disabled passwords, and current software.

What happens if my private key is stolen? If the key had a strong passphrase, the thief cannot use it immediately, which buys you time. Remove the corresponding public key from every authorized_keys file it was installed in, generate a new key pair, and investigate how the file was exposed. A passphrase is what turns a stolen key file from an immediate compromise into a race you can win.

Is a changed host key always an attack? No. It commonly means the server was rebuilt or its host key was legitimately regenerated. It can also mean an attacker is intercepting the connection with their own host key. Because you cannot tell the two apart from the warning alone, the correct response is the same either way: confirm the new fingerprint through a channel you trust before accepting it.

What does the SSH agent do, and is agent forwarding safe? The agent holds your decrypted private key in memory for a session so you type the passphrase once instead of on every connection. Agent forwarding extends that agent to a remote host so you can hop onward without copying the key there. It is convenient and it carries a risk: anyone with root on the intermediate host can use your forwarded agent to authenticate as you while the connection is live. Forward the agent only to hosts you fully trust, or use jump-host configuration that avoids exposing the agent on the intermediate machine.

How do SSH certificates improve on trust on first use? Trust on first use asks each client to verify each server's fingerprint by hand, which scales poorly across a fleet. An SSH certificate authority signs host keys and user keys, so clients trust any host the CA vouches for without a per-host prompt, and servers trust any user key the CA signed. Certificates also carry an expiry, so access ages out automatically rather than lingering in authorized_keys forever. For large environments this replaces the manual fingerprint dance with a central trust root.

Does SSH protect against a compromised server? The host key proves you reached the genuine machine and the channel is encrypted, so no one on the network can read or alter the session. It cannot tell you whether that machine has itself been compromised. If an attacker already controls the server, SSH faithfully delivers your commands and credentials to a hostile host. Server integrity is a separate concern addressed by hardening, monitoring, and least privilege, which is why authentication with a signature rather than a reusable password limits what a compromised server can harvest.

SSH is a quiet workhorse. It turns an open, hostile network into a private channel to a machine you have verified, and it lets you prove your identity with a signature instead of a secret. Learn the two stages, respect the host key warning, and move to keys over passwords, and you have the foundation that every hardening step builds on. To see how exposed remote-access services show up in real intrusions, browse our exploit intelligence dashboard.

Related guides

• SSH Hardening Guide
• How Diffie-Hellman Works
• How the TLS Handshake Works
• Common Ports Reference