How SSH decides you are who you say you are

Two separate identity checks happen in every SSH session: the server proves itself to you, and then you prove yourself to the server. Confusing the two is why host key warnings and login failures often get misdiagnosed.

The server proves itself first

Each server holds a host key pair. Your client caches the fingerprint on first contact, and any later mismatch triggers the loud warning. On Windows, PuTTY stores that cache in the registry; the OpenSSH client uses a known_hosts file in your user profile.

Then you prove yourself

  • Password — simple, brute-forceable, fine for rare access.
  • Public key — your private key signs a challenge; nothing secret crosses the wire.
  • Keyboard-interactive — the server asks questions, which is how one-time codes arrive.
  • Host-based — rare, and it trusts the machine rather than the person.

Where the private key lives on Windows

PuTTY expects a .ppk file and can hold it unlocked in Pageant. The Windows OpenSSH client reads keys from your .ssh folder and can use the ssh-agent service. Both work; pick one per machine so you know which agent is answering.

Agent forwarding, carefully

Forwarding your agent to a jump host lets you hop onward without copying keys there, but anyone with root on that host can use your identity while you are connected. Enable it for hosts you trust, and never as a default.

Questions people ask about this

Is a passphrase on the key the same as a password on the server?
No. The passphrase decrypts the local file on your PC; the server never sees it.
Can I require both a key and a code?
Yes, if the server is configured for multiple required methods. That combination is common for internet-facing jump hosts.

Independent guide. Software names belong to their respective developers; always download from the vendor's own site. Back to all Windows SSH guides.