PuTTYgen usually shows “Couldn’t load private key” when the file is in a foreign format, belongs to the wrong SSH protocol, or is otherwise not the type the PuTTY tool expects. The reliable fix is to import an OpenSSH, ssh.com, or compatible PEM key in PuTTYgen, save a PuTTY-format .ppk copy, select that copy in PuTTY, and verify that the session uses the matching SSH protocol. Keep the original private key unchanged while you work.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What the error actually means
“Couldn’t load private key,” “Unable to use key file,” and similar messages are local file-loading errors. PuTTY, Plink, PSCP, PSFTP, and Pageant are being given a private-key file they cannot parse or cannot use in the selected protocol. The most common case is an SSH-2 private key in OpenSSH or ssh.com format being supplied directly to a PuTTY tool instead of being converted to PuTTY’s native format.
As an Amazon Associate I earn from qualifying purchases.
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 errorsPuTTYgen is the conversion point. It can import supported foreign SSH-2 private-key formats and write a PuTTY private-key file with a .ppk extension. The conversion does not require changing the passphrase; unless you deliberately replace it, the passphrase remains the same.
This error is different from a server rejecting a key after a connection has been made. If PuTTYgen loads the file and PuTTY reaches the server but authentication is refused, the problem is more likely to involve the account, username, authorized key, or server-side permissions. Fix the local loading error first, then diagnose authentication separately.
#1 Best Overall
Quick diagnosis: identify which failure you have
| What you see | What it usually indicates | First action |
|---|---|---|
| PuTTYgen immediately says “Couldn’t load private key” | The file is an unsupported or foreign encoding, the key is damaged, or the selected protocol and key type do not match. | Confirm the source format, then use Conversions → Import Key in PuTTYgen. |
| PuTTY says “Unable to use key file” before authentication | PuTTY is being pointed at a format it cannot use directly, or at the wrong file. | Select the converted .ppk file in the SSH authentication settings. |
| PuTTYgen loads the key, but the server later refuses it | The file was parsed locally; the failure is now an authentication or server-configuration issue. | Check the username, account, authorized key, and server permissions. |
| The key works with one SSH program but not a PuTTY tool | The programs expect different private-key containers or the session protocols differ. | Convert the key to .ppk and verify SSH-2 versus SSH-1. |
Do not infer a server-side problem from a message that appears before PuTTY sends an authentication attempt. A local load error is primarily a file-format or key-type problem.
Before converting anything: protect the original key
- Make a backup of the original private-key file in a protected location. Do not overwrite it during conversion.
- Record where the key came from: OpenSSH, ssh.com, PEM, or an existing PuTTY
.ppkfile. The extension alone may not identify the encoding reliably. - Keep the passphrase available. Importing a passphrase-protected key normally prompts for that passphrase; conversion does not remove it unless you choose to change the key’s protection.
- Use the copy you intend to convert, not a public-key file. A public key can be installed on a server, but it cannot authenticate as the private half of the pair.
- Do not paste a private key into a web converter or an online troubleshooting form. The private key should remain under your control.
The primary fix: import the key and save a PPK copy
Use this path for an OpenSSH or ssh.com private key, and for a PEM file that PuTTYgen recognizes as one of those supported key types.
- Open PuTTYgen. Start the PuTTYgen application that belongs to your PuTTY installation. The exact layout can vary by release, but the conversion command is under the Conversions menu.
- Choose the import command. Select Conversions → Import Key. This is different from opening an already converted PPK file in the normal key-loading area.
- Select the original private key. Browse to the OpenSSH, ssh.com, or recognized PEM file. If the file picker hides it because of a filter, change the picker to show all files rather than renaming the key blindly.
- Enter the passphrase when asked. A protected key cannot be imported without its existing passphrase. Entering a new passphrase at this stage is not required for a straightforward format conversion.
- Confirm that PuTTYgen has parsed the key. The window should display the imported key’s information instead of an error. If the import fails, stop and use the troubleshooting branches below; do not delete the original.
- Save the native PuTTY file. Select Save private key, choose a new destination, and give the file a
.ppkextension. Save it beside the original only if the two names are unmistakably different. - Preserve or deliberately change protection. Keep the existing passphrase unless you have a documented reason to replace it. If you change it, record the new passphrase securely; the old one will no longer unlock the saved copy.
- Point PuTTY at the new file. In the PuTTY session configuration, open the SSH authentication settings and set the private-key file field to the newly saved
.ppk. UI labels can differ between releases, but the setting is the private key used for authentication, not the host-key or general SSH settings. - Check the protocol selection. Set the session to SSH-2 when the imported key is an SSH-2 key. SSH-1 and SSH-2 use different private-key formats; a key created for one cannot simply be substituted for the other.
- Reconnect. Save the session if you use it repeatedly, then connect again. A successful local load followed by a server rejection is a different diagnostic stage, covered below.
OpenSSH, ssh.com, PEM and PPK: what changes between formats?
| Source file or origin | What PuTTY normally needs | Recommended handling | Passphrase expectation |
|---|---|---|---|
| OpenSSH private key | PuTTY-native .ppk for direct use by PuTTY tools |
Import through Conversions → Import Key, then use Save private key. | Keep the existing passphrase unless you intentionally change it. |
| ssh.com private key | PuTTY-native .ppk |
Use the same import-and-save workflow. | The import may prompt for the key’s existing passphrase. |
| PEM private key | Either a directly recognized key or a normalized file that PuTTYgen can import | Try the normal import first. If the encoding is not recognized, use the secondary PEM procedure below on a backup copy. | Do not assume normalization removes encryption or changes the passphrase. |
Existing .ppk |
A PuTTY private key that PuTTY should be able to load | Check that you selected the correct file and that the key is compatible with the session protocol. Re-save it only when you have a specific conversion reason. | Use the passphrase assigned to that PPK file. |
“PEM” describes an encoding family rather than a guarantee that every PEM file contains the same key type or encryption scheme. A filename ending in .pem therefore does not by itself prove which import route is correct.
Rank #2
- Used Book in Good Condition
When PuTTYgen rejects a PEM file
If the ordinary import fails because the existing PEM encoding is not recognized, a compatibility procedure is to normalize a backup copy with ssh-keygen, then retry the import. The command is:
ssh-keygen -p -m PEM -f <keyfile>Replace <keyfile> with the path to the backup copy of the private key. The command may ask for the current passphrase and, depending on the key, a replacement passphrase. Read each prompt carefully. The important safety rule is to preserve the untouched original before running any command that rewrites a key file.
- Copy the original PEM file to a separate working file.
- Run
ssh-keygen -p -m PEM -f <keyfile>against that working file. - Complete the passphrase prompts without discarding the original.
- Return to PuTTYgen and choose Conversions → Import Key for the normalized copy.
- Save the successfully imported key as a new
.ppkfile and select that PPK in PuTTY.
This is a compatibility step, not a universal repair for a damaged or mismatched key. If the normalized copy still cannot be imported, retain both originals and investigate whether the file is actually a private key, whether it was truncated, or whether it belongs to a different SSH protocol.
Recommended Free Tools
SSH-1 versus SSH-2: why the protocol matters
SSH-1 and SSH-2 are not interchangeable labels for the same key format. PuTTY documents separate private-key formats for the two protocols. A key generated for SSH-1 cannot simply be used as an SSH-2 key, and converting a foreign container does not change the underlying protocol or make an incompatible key suitable.
- Identify whether the key was created for SSH-1 or SSH-2.
- Match the PuTTY session’s protocol setting to that key.
- Do not treat changing a file extension as a protocol conversion.
- If the server accepts only one protocol, use a key created for that protocol rather than forcing a mismatched file through the client.
For the common OpenSSH-to-PuTTY workflow, the expected target is an SSH-2 PPK. If the protocol origin is unknown, find out how the key was generated or issued before replacing files or changing session settings.
Why PuTTYgen can load a key while PuTTY cannot
PuTTYgen and PuTTY perform different jobs. PuTTYgen is the key-conversion and key-management utility; PuTTY consumes a key during a connection. A successful import proves that PuTTYgen can parse the source file, but PuTTY will still fail if its session points at a different file, if the PPK was saved somewhere inaccessible to the running account, or if the session is configured for the wrong protocol.
PuTTY is still pointing to the original file
After saving the PPK, revisit the private-key file field and browse to the converted copy explicitly. Do not rely on a remembered path or a similarly named original. Save the session after selecting the new file.
The session protocol does not match
Compare the key’s SSH-1 or SSH-2 origin with the session protocol. A correctly converted container cannot compensate for a protocol mismatch.
The error appears only after the connection starts
If PuTTY opens the connection and then reports that the key was refused, the file has passed the local loading stage. Check the login username, the public key installed for that account, and the server’s key and account permissions instead of repeatedly converting the same PPK.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting branches when the normal conversion fails
PuTTYgen says the file is not a private key
- Verify that you selected the private half, not a public-key export or a certificate.
- Use the original file from the key issuer or generator rather than a file copied from a text editor or messaging application.
- Check the file size and compare it with the protected backup. A truncated copy cannot be repaired by changing its extension.
- Try the PEM normalization procedure only on a copy if the file is known to be a PEM private key.
The passphrase is rejected
- Confirm that you are entering the passphrase for this exact key, not the password for the remote account.
- Check keyboard layout, capitalization, and accidental spaces.
- Do not keep guessing against the only copy. Make a backup and verify the key’s origin with whoever issued it.
The PPK saves successfully but PuTTY still reports “Unable to use key file”
- Reopen the PPK in PuTTYgen to confirm that the saved file is readable.
- Ensure PuTTY is selecting that PPK rather than the original OpenSSH, ssh.com, or PEM file.
- Check that the file path is correct for the account running PuTTY and that the file was not moved after the session was configured.
- Verify the SSH-1 or SSH-2 session setting.
The key loads, but authentication is refused
- Confirm the username in the PuTTY session.
- Confirm that the matching public key is installed for that account on the server.
- Check the server account and authorized-key permissions according to the server administrator’s policy.
- Keep this diagnosis separate from local conversion: a server-side refusal does not mean the PPK failed to load.
Conversion choices at a glance
| Situation | Preferred action | Risk or limitation |
|---|---|---|
| OpenSSH or ssh.com key, PuTTY reports a load error | Import in PuTTYgen and save a new .ppk. |
Requires the key’s passphrase if it is protected; does not change the underlying protocol. |
| Recognized PEM key | Import directly in PuTTYgen, then save as PPK. | PEM is an encoding label, so recognition depends on the actual key content and release. |
| PEM key is not recognized | Back up the file, run ssh-keygen -p -m PEM -f <keyfile> on the copy, and retry import. |
It rewrites the working copy; never use it as a reason to overwrite the only original. |
| PuTTYgen loads the key but the server refuses it | Stop converting and check username, authorized key, account, and permissions. | This is an authentication-stage problem, not normally a local format problem. |
| SSH-1 and SSH-2 do not match | Use a key and session configured for the same protocol. | Changing the extension or saving as PPK does not convert SSH-1 into SSH-2. |
A short verification checklist
- The original private key is backed up and unchanged.
- The source format and SSH protocol are identified as far as the key’s issuer or generator documents them.
- PuTTYgen’s Conversions → Import Key path was used for a foreign format.
- The converted file was saved as a new
.ppkfile. - The original passphrase was retained unless a deliberate replacement was made.
- PuTTY’s SSH authentication private-key field points to the new PPK.
- The PuTTY session protocol matches the key.
- Any later “key refused” message is being handled as a server authentication issue, not as another conversion failure.
When to stop converting and obtain a new key
Conversion is appropriate when the private key is intact and only the container format is unsuitable. It is not a substitute for recovering a missing, truncated, or irreversibly corrupted private key. If no backup can be imported, the passphrase is unavailable, or the key’s origin and protocol cannot be established, ask the key owner or server administrator whether a new key pair should be generated and its public key installed. Keep any surviving original files until access has been confirmed with the replacement.
Bottom line
The dependable repair for PuTTYgen’s “Couldn’t load private key” message is format-aware conversion: preserve the original, import the foreign key through Conversions → Import Key, save a new PuTTY .ppk, select that file in PuTTY, and match SSH-1 or SSH-2. If the key loads but the server rejects authentication, stop treating it as a file-format error and investigate the account and authorized-key configuration instead.
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.
