Public key rejected

What “Public key rejected” usually means

When PuTTY reports Public key, the client has already attempted a network or protocol step and failed before a normal interactive shell is available. This guide explains what the message usually means on Windows clients, which local settings to verify first, and when the problem is almost certainly on the server, firewall, or DNS path rather than inside the PuTTY GUI.

A public-key authentication attempt was offered and declined. The private key may be wrong, the public half missing on the server, or the server disallows that key type.

Independent resource: Putty.info is educational only and is not affiliated with the official PuTTY project. Compare symptoms against the official documentation for your installed version.

Symptoms you will see

Operators usually notice this failure in one of a few repeatable ways. Capture the exact dialog text, the hostname and port from the Session panel, and whether the failure happens before or after a username prompt—those details decide which checklist below applies.

  • Auth continues to password (if enabled) after key is rejected.
  • Verbose logs show Offering public key then rejection.

Likely causes ranked by frequency

Several independent conditions can produce the same client-facing wording. Work from the outside in: reachability first, protocol selection second, authentication third. Changing key files will not fix a TCP refusal, and opening a wider firewall will not fix a rejected public key.

  • authorized_keys missing the matching public line.
  • Wrong account home directory / wrong authorized_keys path.
  • Key type disabled in sshd HostKeyAlgorithms/PubkeyAcceptedAlgorithms style policies.
  • Corrupt PPK or passphrase entry mistakes leading to wrong key material.

Step-by-step client checks

Use this ordered checklist on a workstation you control. Prefer saved sessions so Host Name, Port, and Connection type stay consistent while you isolate one variable at a time.

  1. Open the PPK in PuTTYgen and copy the authorized_keys line; compare byte-for-byte to the server file.
  2. Confirm username and server hostname—keys installed on bastion A do not help bastion B.
  3. Check Pageant’s key list for duplicates/old keys confusing operators.
  4. Validate ~/.ssh permissions (700) and authorized_keys (600) ownership.
  5. Try a freshly generated test key on a non-production account to isolate policy vs file mistakes.
  6. Review server logs for explicit rejection reasons.

Do not paste private keys, passphrases, or production passwords into Putty.info tools or contact forms. Diagnose locally with PuTTY, Plink, PSCP, or PSFTP from an official install.

When it is a server or network issue

Administrators should document accepted key types and provide a paste-safe onboarding path. Rejecting obsolete algorithms is good hygiene if clients are guided to upgrade.

If TCP connects from another network path but fails from yours, involve the network team with traceroute/path evidence rather than repeatedly regenerating keys. If authentication fails after a banner appears, collect the server sshd logs for the same timestamp and username—client-side retries alone rarely reveal AccountLocked, Match blocks, or AllowUsers denials.

Sources

  • PuTTY Documentation — Simon Tatham / PuTTY Project · verified 2026-09-03 04:12:04
  • PuTTY FAQ — Simon Tatham / PuTTY Project · verified 2026-09-03 04:12:04