We've spent time on how the server verifies the user. But how does the user verify the server? In a Man-in-the-Middle (MitM) attack, an attacker can spoof a server and trick you into sending your credentials. SSH solves this through Host Key Verification.
The first time you connect to a server, SSH shows you a fingerprint of the server's public host key and asks: 'The authenticity of host... can't be established. Are you sure you want to continue?'. If you say 'yes', the key is saved to your `~/.ssh/known_hosts` file. This is the 'Trust On First Use' (TOFU) model.
💡 The danger of TOFU is that if an attacker is already MitM-ing your first connection, you are trusting the attacker's key, not the server's.
On every subsequent connection, SSH compares the server's presented key with the one stored in `known_hosts`. If they differ, SSH produces a massive, scary warning: 'WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!'
⚠️ Never ignore the 'Remote Host Identification Has Changed' warning by simply deleting the line from `known_hosts`. This warning is often the only indicator that a MitM attack is occurring.
| Scenario | Result | Action |
|---|---|---|
| First Connection | Prompt for trust | Verify fingerprint via OOB channel |
| Key Matches | Silent connection | Proceed normally |
| Key Mismatch | CRITICAL WARNING | Investigate for MitM or Server Re-install |
To avoid the 'blind trust' of TOFU, SSHFP (SSH Fingerprint) allows administrators to publish the server's host key fingerprint in a DNS record. If the client is configured to use DNSSEC, it can verify the host key via DNS *before* the first connection, eliminating the need for the 'Are you sure?' prompt.
# Example of a DNS query for an SSHFP record
dig SSHFP example.com +shortSetting `StrictHostKeyChecking no` in your SSH config is a catastrophic security failure. It disables all host verification, making you a perfect target for MitM attacks.
Verify exercises to earn ★ 150 XP and unlock next lab level.