Fingerprint Verification
Overview
“Fingerprint Verification” walks through user-key handling with PuTTYgen, Pageant, and the PuTTY Auth settings—always on machines you control.
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.
Public-key authentication separates a public half you install on servers from a private half that must never leave systems you trust. PuTTY traditionally stores private keys as .ppk files managed with PuTTYgen; OpenSSH on Linux expects different encodings, so conversion is a normal part of mixed estates.
PuTTY UI panels involved
You will primarily use PuTTYgen for generation/conversion, Pageant for agent loading, and PuTTY’s Connection → SSH → Auth controls to select a PPK or defer to the agent. Session still defines the destination host and port.
Typical panels: run PuTTYgen to generate or convert keys; use Pageant to unlock keys into memory; in PuTTY itself open Connection → SSH → Auth → Credentials (wording varies slightly by version) to select a PPK or rely on Pageant. Session → Host Name still needs the correct target—keys do not override DNS or port mistakes.
Step-by-step procedure
Procedure:
- Generate or convert keys only with official PuTTYgen locally—never in a browser.
- Set a strong passphrase when saving the private PPK; store recovery material per policy.
- Copy the public key line into the correct account’s authorized_keys on the server.
- Fix ~/.ssh directory and file permissions so sshd will honour the file.
- Configure PuTTY or Pageant to present the private key; test on a non-production host.
- Inventory where the public key was installed to enable later rotation/revocation.
Never upload a private key to a “web converter,” never email a PPK, and never store unencrypted production keys in shared cloud sync folders without additional controls.
Failures, permissions, and recovery
Failure and recovery notes:
- Losing the private key without a backup means you must use alternate admin paths to install a new public key.
- Uploading private keys to “helper” websites is a compromise.
- Agent forwarding broadens exposure—see dedicated risk guides before enabling.
- Host keys and user keys solve different problems; do not delete host-key cache to fix user auth.
Server-side installation usually means appending the public key line to ~/.ssh/authorized_keys with correct permissions on ~/.ssh and the authorized_keys file. If the server rejects the key, confirm the account, the key type allowed by sshd_config, and that you copied the public key—not the private key—into authorized_keys.
Lifecycle: inventory, rotation, revocation
Inventory every server where a public key is installed so rotation and revocation are possible. Orphaned keys outlive employee laptops and become silent backdoors.
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 Fingerprint Verification (path /ssh-keys/fingerprint-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.