Permission denied
What “Permission denied” usually means
When PuTTY reports Permission denied, 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.
The SSH transport likely came up, but the account or authentication method was rejected. Wording varies (“Access denied”, “Permission denied”, public key rejected). Treat this as an authz/authn problem once you know TCP and host keys succeeded.
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.
- Repeated password prompts followed by denial.
- Immediate failure when only public-key auth is offered.
- Success with another account on the same host, proving the service itself is up.
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.
- Wrong username (root vs ubuntu vs cloud-user vs corporate ID).
- Public key not installed in the correct account’s authorized_keys.
- Wrong PPK selected under Connection → SSH → Auth, or Pageant lacking the key.
- sshd PermitRootLogin / PasswordAuthentication / PubkeyAuthentication policy mismatches.
- Account locked, expired, or restricted by AllowUsers/AllowGroups/Match blocks.
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.
- Confirm username spelling and the intended account in your inventory.
- Verify the PPK path or Pageant key list; open PuTTYgen to ensure the public blob matches what you installed.
- Try an interactive password login only if policy allows—failure modes differ and teach which method the server offers.
- Check server auth logs for the same timestamp: invalid user, Failed publickey, or Accepted.
- Confirm file modes on ~/.ssh and authorized_keys; sshd ignores overly permissive files.
- Ensure you are not hitting a force-command or Match block that denies interactive shells for that key.
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
Most stubborn cases are server-side: wrong authorized_keys file for the chrooted user, SELinux contexts, or a configuration that disables the key algorithm you generated (for example restricting to certain key types). Client retries without log access rarely converge.
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.