Diagnosing Putty SSH Key Authentication Failures Due to Format and Permission Issues

Recognizable Condition: Putty Falls Back to Password Authentication

You attempt to connect via Putty, but the session immediately prompts for a password, even though an SSH key is configured on the client. Public-key authentication is silently skipped.

Diagnostic Table: Symptom vs Likely Cause

Symptom	Likely Cause	Quick Check
Putty prompts for password on every connect	Key is in OpenSSH PEM format, not .ppk	Check Putty Auth panel for .ppk path
Public-key auth never offered	Pageant not carrying the .ppk key	Start Pageant, load .ppk, verify tray icon
Authentication fails after key is offered	Server authorized_keys has wrong permissions or ownership	Run ls -la ~/.ssh/authorized_keys on server
Key rejected with "no acceptable key type"	SSH server restricts acceptable key types (e.g., Ed25519 only)	Check server KexAlgorithms or HostKeyAlgorithms

Ordered Diagnostic Checks

1. Verify the .ppk key path in Putty. In Putty, go to Connection → SSH → Auth. Confirm the .ppk file path is listed and the key appears in the key list. If the path points to a PEM file, Putty will not use it for public-key auth.
2. Load the .ppk key in Pageant. Start the Pageant application, add the .ppk key, and ensure the tray icon reflects the loaded key. Putty reads Pageant’s key selection automatically; without this step, Putty has no .ppk to offer.
3. Check server-side authorized_keys permissions. Connect via ssh -v user@host and observe the log. Look for lines containing "Offering public key" and "Accepted public key". If the key is offered but not accepted, SSH into the server and run:

   chmod 600 ~/.ssh/authorized_keys

   and

   chmod 700 ~/.ssh

   . Incorrect modes (e.g., 644 on authorized_keys, 777 on .ssh directory) cause the daemon to reject the key.
4. Confirm the SSH server’s acceptable key types. Some servers configure TrustedUserKeysOnly or restrictive HostKeyAlgorithms that exclude RSA or ECDSA. If your Putty-generated .ppk uses an unsupported type, authentication fails immediately. On the server, check /etc/ssh/sshd_config for PubkeyAuthentication, AuthorizedKeysFile, and any TrustedUserKeys directives.

Fixes Tied to Findings

If the .ppk format is missing: Convert the OpenSSH PEM key to .ppk using puttygen. On the client machine, run:

puttygen -key ~/.ssh/id_rsa -ppk ~/.ssh/id_rsa.ppk

Then ensure the .ppk path is set in Putty’s Auth panel and the key is loaded in Pageant.

If Pageant is not carrying the key: In Pageant, use its interface to import the .ppk file. The tray icon should change to show the key is active. Putty will then select it automatically during connection.

If authorized_keys permissions are wrong: Apply the correct modes as in step 3 above. Also verify ownership: the file should be readable only by the account owner, and the .ssh directory should be owned by that account.

If the server rejects the key type: Either regenerate the key pair using a supported algorithm (e.g., Ed25519 or RSA-2048/4096) or adjust the server’s KexAlgorithms/HostKeyAlgorithms to include the key’s type. Note that modifying server configuration requires restarting the SSH daemon and may affect other users.

Verification After Fixes

After applying a fix, reconnect via Putty. Open the SSH session log (Putty shows connection output in the session window or via ssh -v from a terminal). You should see "Offering public key" followed by "Accepted public key" if key authentication succeeds. If password prompt returns, revisit the checklist in order.

As a cross-check, run ssh -v user@host from a standard terminal. The presence of "Offering public key" followed by "Accepted public key" confirms the key was offered and accepted, independent of Putty’s Pageant integration.

Limitations and Escalation Criteria

• Adding or modifying authorized_keys as root without understanding the implications can lock you out of SSH access entirely. Always test as the target user first.
• Using an outdated .ppk key with Pageant may cause rejection if the underlying SSH key was regenerated without re-adding the new .ppk to Pageant.
• Assuming all key types work equally across servers; some production servers disable RSA or ECDSA by default, leading to silent authentication failures.

Escalation: If the above checks and fixes do not resolve the issue, verify that the server’s SSH configuration permits the key type in use, confirm network-level firewall rules allow the connection, and consider consulting the server administrator about key-pair generation policies or TrustedUserKeys configuration.