Host Key Verification
Security overview for this topic
Independent resource: Putty.info is not affiliated with, operated by, sponsored by, or endorsed by the official PuTTY project. We never host PuTTY binaries. Prefer the project's own download page and documentation.
This security guide covers “Host Key Verification” for Windows operators who use PuTTY daily. Controls only work when the client binary is authentic, host keys are verified, and private keys stay protected.
Security on an SSH workstation is layered: obtain an authentic client binary, verify host keys, protect user private keys, limit agent exposure, and treat session logs and clipboards as sensitive. Skipping any layer creates a false sense of safety—especially when operators equate “the terminal window looks normal” with “the endpoint is trustworthy.”
How this shows up in PuTTY
Apply “Host Key Verification” by inspecting the relevant PuTTY categories deliberately—Session for target identity, Connection → SSH → Auth for user keys, Tunnels for forwarding exposure, and logging panels for transcript risk—rather than clicking through defaults on a shared bastion laptop.
In the PuTTY configuration tree, prioritize Connection → SSH → Auth for key selection, Connection → SSH for protocol algorithms when policy requires it, and Connection → SSH → Tunnels only after you understand who can reach the forwarded port. Window → Behaviour and logging features are productivity tools; enable them deliberately because transcripts may capture secrets typed into remote shells.
Practical controls and steps
Recommended control sequence:
- Confirm your PuTTY build comes from official hosts via /download/ and Help → About.
- Verify host key fingerprints out-of-band on first connect and on any change warning.
- Use passphrase-protected PPKs; load via Pageant for interactive work when appropriate.
- Disable agent forwarding and unused tunnels by default; enable per session only with a ticket.
- Keep session logging off unless required; protect and redact transcripts that exist.
- Rotate and revoke keys on personnel changes; monitor official advisories for client updates.
Warnings and failure modes
Operational warnings specific to this topic:
- Ignoring warnings related to Host Key Verification to “just get in” is how impersonation and key theft incidents start.
- Browser-based key generators and online PPK converters are unsafe.
- Clipboard history tools can retain passwords pasted into remote passwd prompts.
- Old installers from random sites may be trojaned even if the filename looks right.
If you suspect a compromised private key, revoke the matching public key on every server, rotate credentials, and review auth logs before restoring access. Do not keep using a key “just for one more jump host.”
Authoritative sources
Cross-check release and advisory information against official project pages rather than social media summaries. Putty.info links monitored sources from advisories and versions, but the publisher’s own pages remain authoritative.
Primary references: official latest download page, official PuTTY documentation, and this site's official-download redirect plus safe download guide and latest version notes.
Field notes and runbook extras
Additional operational depth for Host Key Verification (path /security/host-key-verification/): treat every change to authentication, forwarding, or host-key storage as a reversible change under change control. Record the PuTTY version string from Help → About, the Windows build, and whether Pageant was running. Those three facts explain a surprising fraction of “it works on my laptop” discrepancies.
When documenting the procedure for teammates, include: the saved session name, Host Name and Port from the Session panel, whether Connection type is SSH, the username, whether a PPK path is set under Connection → SSH → Auth, and whether agent forwarding is enabled. Explicitly state that Putty.info is an independent educational site and that binaries must be obtained from the official project download page. Link readers to safe download guidance, host key verification, and the official manual so they can cross-check labels that differ slightly across releases.
If you still need more diagnostics after following the sections above, reproduce the issue with logging enabled under Session → Logging to a local file you control, scrub secrets from the transcript, and compare against server auth logs for the same UTC timestamp. Avoid third-party “PuTTY fix” utilities. Prefer updating to the current stable release from official hosts, re-importing a known-good saved session, and testing from a second network path before declaring the workstation broken.
- Keep private keys passphrase-protected and backed up offline according to your organization's secret-handling policy.
- Prefer named saved sessions over ad-hoc connections for anything beyond a one-off debug.
- Disable unused tunnels and agent forwarding by default; enable them per session only when required.
- Schedule periodic key rotation and remove stale authorized_keys entries during access reviews.
- Teach new operators the difference between connection errors and authentication errors before giving them production bastion access.