iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
PuTTY’s “Server refused our key” message means the SSH connection reached public-key authentication, PuTTY offered a public key, and the remote SSH server rejected it. The usual causes are a wrong username, a private key that does not match the installed public key, a damaged or misplaced authorized_keys entry, incorrect ownership or permissions, or an SSH policy that disallows the key.
Work from the identity outward: verify the account, verify the matching .ppk, inspect the target account’s key file, repair access controls, then use PuTTY and server logs to identify any remaining policy restriction.
What “server refused our key” actually tells you
This error is more specific than a generic connection failure. PuTTY has already reached the SSH service and progressed far enough to offer a public key for authentication. The server—not PuTTY’s network connection—declined that key for the account being used.
The PuTTY manual describes this as the server refusing to accept the public key it was offered. In most cases, the server is not configured to accept that key for that user. PuTTY also identifies incorrect ownership or permissions on the user’s home directory or public-key files as common causes. The practical consequence is that replacing PuTTY or changing the Windows network connection is rarely the first fix. Check the remote account and SSH configuration first.
A related PuTTY message, “No supported authentication methods available”, can appear when the server offers no method that PuTTY can use, or after every offered method has been rejected. The same identity, key-file, and server-policy checks below will usually distinguish the two situations.
Find the fault before changing anything
Use this order to keep client-side and server-side problems separate. Do not regenerate keys or edit the daemon configuration until you know which layer failed.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Layer | What to verify | Evidence of a fault |
|---|---|---|
| Remote identity | The username in PuTTY is the account that owns the installed key | The key is present, but under another user’s home directory |
| PuTTY key selection | The selected private key corresponds to the server’s public key | PuTTY offers a key whose fingerprint or contents differ from authorized_keys |
| Key-file integrity | The complete public-key line is in the expected authorized_keys file |
The line is wrapped, truncated, altered, or installed in another account |
| Access controls | Home directory, .ssh, and authorized_keys have acceptable owner and mode |
Server logs mention bad ownership, insecure permissions, or an unreadable file |
| SSH policy | Public-key authentication, the key path, and the algorithm are enabled | The server log names a disabled method, account restriction, or policy rejection |
| Authentication evidence | PuTTY Event Log and the server authentication log for the same attempt | The logs identify a different key, account, path, or policy than expected |
Step 1: Confirm the remote username
SSH keys are authorized per account. A key in /home/alice/.ssh/authorized_keys does not authenticate a session that logs in as bob, even when both users are on the same server.
- Open the saved PuTTY session.
- Go to Connection > Data.
- Set Auto-login username to the intended remote account, or leave it blank and enter the username when PuTTY prompts.
- Reconnect and make sure the prompt, if shown, contains exactly that account name, including capitalization where the server treats names as case-sensitive.
For a cloud image, use the image provider’s documented default operating-system account rather than assuming root or your local Windows name. AWS specifically directs PuTTY users who see this error to verify the username associated with the AMI. If you have console or another administrative access, check which home directory contains the key and which account owns it.
Step 2: Select the private key that matches
The file selected in PuTTY must be the private half of the public key installed on the server. A different key generated on the same computer, an older backup, or a key belonging to another administrator will be rejected even if its filename looks plausible.
Rank #2
- Portable Design: 11.2" L x 7.3" W x 1.6" T. Optimized key case holds up to 24 keys. Optimal choice for bankers, businessmen, landlords, hotel managers, real estate agents, car dealers, etc.
- Watertight & Fireproof: With soft and smooth silicone coating, it can resist high temperature up to 2000 °F. Effectively protect keys from heat, water or other extreme conditions.
- Reliable & Reusable: Perfect 3-layer covers with excellent durability. Outer layer: protective silicone coating and fiberglass fabric. Middle layer: cardboard for supporting the whole structure. Inner layer: cozy oxford cloth.
- Flexible Hooks: Come with sturdy ABS hooks rotating freely to flexibly arrange multiple keys. Firmly fixed by thick and well-sewn nylon straps, they are long-lasting and unlikely to fall out.
- 24 Key Tags: Contain soft and pliable key tags (10 colors) with removable labels to write and clear windows for easy visibility. Great readable method to track your keys quickly.
- In PuTTY, open Connection > SSH > Auth.
- Under the private-key setting, click Browse and choose the intended
.ppkfile. - Confirm that any passphrase prompt is for that key and that you can unlock it.
- Save the session only after checking the path, so a later connection does not silently revert to a different saved configuration.
PuTTY uses its own PuTTY Private Key format. If the only copy you have is an OpenSSH private key or another foreign format, open PuTTYgen, choose the import option for that format, load the private key, and use Save private key to create a .ppk. Then select the newly saved file in PuTTY. Importing changes the container format; it does not create a new key pair, so the resulting public key must still correspond to the line installed on the server.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteIf you can access the server through a console, compare the public-key fingerprint or the complete public-key material generated from the selected private key with the entry in authorized_keys. Do not compare only the filename.
Step 3: Inspect the target account’s authorized_keys file
For the verified username, inspect that account’s home directory and the file SSH is configured to read. The normal location is ~/.ssh/authorized_keys, but the daemon can be configured with a different path. Microsoft’s SSH troubleshooting guidance lists a missing or incorrect authorized_keys file as a cause of public-key failures.
- Change to the target account’s home directory, not an administrator’s home directory.
- List the SSH directory and file, for example with
ls -ld ~/.sshandls -l ~/.ssh/authorized_keys. - Open the file in a text editor that does not reflow long lines.
- Verify that the public key corresponding to the selected private key is present as one complete line.
An entry normally starts with a key type, followed by a base64-encoded key, and may end with a comment. The comment is not the identity check; the key data is. Remove accidental wrapping, leading or trailing characters, smart quotes, and control characters introduced while copying. A line broken at the edge of a terminal window is not necessarily damaged, but an actual newline inside the key data is.
Check for the common placement errors:
- The key was added to
/root/.ssh/authorized_keyswhile the session logs in as an ordinary user. - The key was placed in a similarly named account’s home directory.
- The file is named
authorized_keys.txtor has another extension. - The server is configured to use a nonstandard
AuthorizedKeysFilepath. - The copied line belongs to a different key pair or was truncated during transfer.
If several keys are present, leave unrelated entries in place while troubleshooting, but make the intended line easy to identify by its comment or fingerprint. Do not paste the private key into the server; only the public key belongs in authorized_keys.
Step 4: Repair ownership and permissions
OpenSSH commonly refuses to use a key when the home directory or SSH files can be modified by an inappropriate user. The exact acceptable modes can vary with the operating system, ACLs, daemon settings, and security policy, but a frequently used Unix baseline is:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysRun those commands as the target account or an administrator who understands the account’s layout. Then verify ownership. A typical administrative repair, with the placeholders replaced by the real account and path, is:
chown -R username:username /home/username/.sshAlso inspect the home directory itself. It should be owned by the intended account and should not be writable by unrelated users. On many systems, removing group and other write permission from the home directory is appropriate, but do not apply a mode that conflicts with a deliberate shared-directory design. If the account uses a nonstandard home path, substitute that path rather than assuming /home/username.
After changing access controls, recheck with directory listings and test again. If the server still refuses the key, look at ACLs, SELinux or another mandatory access-control system, and network-mounted home directories. A normal-looking mode from ls does not prove that an ACL or security context permits the SSH daemon to read the file.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Step 5: Check the SSH server policy
When the username, key pair, file contents, and permissions are correct, inspect the daemon’s effective configuration and account restrictions.
Rank #4
- PRODUCT DIMENSIONS: approximately 8.25 x 9.8 x 1.57 inches, medium size with 24 key keychains for easy to carry.
- LARGE CAPACITY: This leather key case helps to stay stay neat & organized. It contains 24 key rings with labeling position, convenient to distinguish the keys, you just need to write the description on the paper and insert it into the corresponding label card slot.
- MAKE THE BEST FIRST IMPRESSION: Inspired by sleek design. This professional portfolio leather folder is made of high-grade PU fabrics for a high-end look at an affordable price. Durable, smooth and shiny, feels good! Individuation key ring design, the structure is easy to assemble and disassemble.
- EXCELLENT OFFICE APPLIANCES: This portable key bag is perfect for banker, hotel executives, lawyers, businessmen, landlord, property managers & more. It is especially suitable for estate agents and car rental service, car dealerships and repair shops!
- SUPERIOR SERVICES : We are committed to quality products and superior service. Just contact us if you have any product quality problem and we will solve the problem for you ASAP.
- Confirm that public-key authentication is enabled.
- Confirm the daemon is reading the expected authorized-keys path.
- Check whether a
Matchblock changes settings for this user, group, source address, or connection. - Verify that the key algorithm and signature type are allowed by the server’s current SSH policy.
- Look for account restrictions such as an expired or locked account, a denied shell, an allow/deny user list, a forced command, or a certificate or principal requirement.
Do not broadly weaken cryptographic policy just to make one key work. If the log identifies an algorithm that is disabled, generate or provision a key type supported by the server’s policy, or make a narrowly scoped policy change approved by the system owner. A key can be mathematically valid and still be rejected because the server no longer permits its algorithm or signature scheme.
If you edit the daemon configuration, validate the syntax with the platform’s supported configuration-test command before reloading the service. Keep an existing administrative session open while testing so a configuration mistake does not lock you out.
Step 6: Read PuTTY’s Event Log and the server log together
PuTTY’s manual recommends checking the Event Log. In an open session, use the window menu and choose Event Log. Record which username PuTTY is using, which key it offers, and any diagnostic text from the server. The log can reveal that PuTTY offered a different key than the one you selected, particularly when an authentication agent is active.
At the same time, inspect the SSH authentication log or system journal on the server at the exact time of the attempt. Depending on the operating system, this may be a distribution-specific authentication log or entries viewed through the system journal. Search for the username and timestamp rather than relying on a generic “failed login” counter.
Typical server-side messages map to actions as follows:
Best Value
- Package Includes: Pack Of 1 Piece Large Key Holder And 28 Piece Small Key Ring And 30 Piece Assorted Color Plastic Key Tags
- Size Information: This Silver Key Organizer Length Is About 5.9 Inches (15 cm), Width Is About 5.5 Inches (14 cm), Made Of High Quality Stainless Steel
- Unique Design: Smooth Plastic Handle,Safe For Your Hand,1-28 Numbers Mark On Key Chain,Also Come With 28 Separable Portable Key Rings,So Easy To Distinguish,You'll Need To Assemble The Key Rings And Key Tags By Yourself
- Effective Management: 30 Assorted Color Black Green Red Blue Yellow Plastic Key Tags,Organize And Identify With Assorted Colors Tag With Blank Inserts
- Widely Used: Great For Large Family Multi Key Management, Hotel, Rental Housing,School, Factory Warehouse, Office, Home, Apartments And Workshop Use
| Log evidence | Likely action |
|---|---|
| Unknown user, invalid user, or account not allowed | Correct the PuTTY username or the server’s account-access policy. |
| Authentication refused because the key is absent | Install the matching public key in the correct account and path. |
Bad ownership or modes for home, .ssh, or authorized_keys |
Repair owner, mode, ACL, or security context, then retry. |
| Key type or signature algorithm not permitted | Use a key and signature method allowed by the server’s current policy. |
| Forced command, source restriction, or policy match | Review the key options and effective per-user or per-source configuration. |
| No server-side entry for the attempt | Confirm the address, port, SSH service, and that you are reading the correct host’s log. |
Do not treat a client-side message as proof that the server saw the intended key. The two logs together establish the account, offered identity, and rejection reason.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 7: Retest with exactly one identity
Multiple identities can hide a simple mismatch. PuTTY may offer a key loaded in Pageant before or alongside the key configured in the session. A server may also impose an authentication-attempt limit.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors- Temporarily disable the option that lets PuTTY use Pageant, or clear unrelated keys from Pageant.
- Leave only the verified private key selected under Connection > SSH > Auth.
- Use the confirmed username and reconnect.
- Capture a fresh PuTTY Event Log and the corresponding server log entry.
If authentication succeeds with one directly selected key, the earlier failure was caused by an incorrect identity being offered or by too many identities being tried. Re-enable agent use only after deciding which keys should be available for this host.
When the message changes to “no supported authentication methods available”
This wording does not necessarily mean the key file is corrupt. It can mean that the server has disabled public-key authentication, that the server offers only methods PuTTY is not configured to use, or that every offered key was rejected and no fallback method remains.
Check the server’s advertised and configured methods in the log, then verify PuTTY’s settings under Connection > SSH > Auth. If password authentication is intentionally disabled, a working public key or another approved method is required. If the server requires keyboard-interactive, a certificate, or an account-specific mechanism, configure PuTTY for that method only after confirming the server policy.
Cloud images and first-login mistakes
Cloud-provided operating-system images often use a documented, image-specific default account and disable direct root login. The public key supplied during instance creation is usually installed for that default account. Logging in as another name produces a key refusal even though the instance and key pair are otherwise correct.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Use the provider’s instructions for the exact image and operating system, then confirm the resulting home directory on the instance. If the instance was rebuilt, restored from a snapshot, or assigned a new user-data configuration, verify that the expected public key was installed on the current disk rather than on an earlier machine.
Windows-side checks that prevent repeat failures
- Keep private keys in a protected Windows folder and back them up securely; never upload a private key to the server.
- Use descriptive filenames that identify the host or purpose, while remembering that the filename is not proof of the key’s identity.
- After importing a foreign key into PuTTYgen, save the resulting
.ppkand select that exact file in the session. - Review saved-session settings after moving or renaming a key; PuTTY may retain an old path.
- When using Pageant, load only the identities required for the current work and clear stale keys during troubleshooting.
- Keep a record of the public-key fingerprint and the account for which it was installed.
A compact recovery checklist
- Confirm the remote username in Connection > Data > Auto-login username or at the prompt.
- Confirm the selected private key in Connection > SSH > Auth is the matching
.ppk. - If necessary, import the original OpenSSH key with PuTTYgen and save it as
.ppk. - Inspect the target account’s
~/.ssh/authorized_keysand verify one intact matching public-key line. - Check the home directory,
.ssh, andauthorized_keysowner and permissions. - Verify public-key authentication, the authorized-key path, allowed algorithms, and account restrictions.
- Read PuTTY’s Event Log and the server authentication log for the same attempt.
- Retest with Pageant disabled or unrelated identities removed.
Once the server accepts the key, document the working username, key fingerprint, authorized-key path, and any non-default policy. That record makes the next migration, image rebuild, or key rotation far less likely to produce the same refusal.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
