PuTTY requires a private key file in PPK format, while an OpenSSH Linux server allows a public key in the targeted account. These two files do not go in the same place: the PPK remains on your Windows machine, while the public key is added to authorized_keys on the server.
You can create a new pair with PuTTYgen or import an already existing OpenSSH private key. In both cases, keep a functional session or a backup console during the deployment. A newly created key does not provide access to the server until its public part has been authorized.
For the host, port, account, and initial fingerprint verification settings, follow the guide configure the PuTTY connection to your Linux server. Here, the subject is preparing the key and proving that PuTTY is actually using it.
Identify the two keys and the target Linux account
An SSH pair consists of a private key and a public key. The private key serves to prove your identity: never share it and do not place it on the server. PuTTYgen saves it in .ppk format. Protect this file on Windows with a passphrase and, if necessary, keep an encrypted backup in a secure location.
The public key can be communicated to the server. For OpenSSH, it usually appears on a single line in the ~/.ssh/authorized_keys file of the relevant Linux account. The account, its home directory, and the authorized path must be confirmed before any modification. An administrated server can set another location with AuthorizedKeysFile.
The passphrase protects the local private key; it is not the Linux account password. Key-based authentication can also remain subject to a second factor. Finally, the host key verifies the server’s identity: it is different from your user key and must always be checked.
Create a pair with PuTTYgen and save the PPK
On the Windows machine, open PuTTYgen. Choose EdDSA with Ed25519 if the server and its policy accept it. Depending on the version, the type label may vary. RSA remains a compatibility option if the environment requires it; do not reactivate an old SHA-1 or SSH-1 signature to work around a client issue. If you prefer to create the pair from an Ubuntu machine, follow this guide to generate an SSH key from Ubuntu; PuTTYgen remains the method described here for Windows.
Click on Generate and follow the tool’s request for mouse movement. Add a recognizable comment that reveals no sensitive information. Fill in Key passphrase and Confirm passphrase, then click on Save private key. Choose a private folder accessible only to authorized users of your machine and note the location of the .ppk file. Generating alone does not save the file.
Copy the value displayed in Public key for pasting into OpenSSH authorized_keys file. This line will need to be added to the Linux account. The Save public key button may produce a different format, notably RFC 4716. Do not paste a BEGIN SSH2 PUBLIC KEY block into the OpenSSH file. Keep the PPK format settings proposed by PuTTYgen; if a client cannot read the format, update it instead of weakening the key’s protection.
Import an existing OpenSSH key as PPK
If you already have the OpenSSH private key, import it on the Windows machine with PuTTYgen: choose Conversions > Import key, select the private file, then enter its passphrase if PuTTYgen prompts for it. Then, save a copy in PPK format using Save private key.
This operation converts the container for PuTTY; it does not create a new identity. The public key and its fingerprint must remain those of the original pair. Verify the fingerprint in PuTTYgen before and after the import, then ensure that the corresponding public key is indeed authorized on the Linux account. A public key alone, often named with the .pub extension, does not allow reconstruction of the private key. Renaming a .pem file to .ppk does not convert it either: the formats differ, it needs to be imported and verified that PuTTYgen recognizes it.
Do not transmit your private key to a web converter and do not retrieve it from a root account on the server. If it is lost or if its passphrase is forgotten, create a new pair, authorize its public key via a backup access, test it, and then remove the old authorization if it is no longer necessary.
Add the public key to the correct account without overwriting others
The following commands are executed in a Linux shell already opened under the target account, not in PowerShell and not automatically under root. They primarily serve to confirm the identity of the account and the paths involved:
whoami
printf '%sn' "$HOME"
ls -ld "$HOME" "$HOME/.ssh"
ls -l "$HOME/.ssh/authorized_keys"Check that whoami displays the expected account and that $HOME is its home directory. The ls commands allow you to control the existence, ownership, and permissions of the folder and the file. A message indicating that a path does not exist may be normal for a first installation. Do not inadvertently create files in the root directory.
In the standard case where you are correctly logged in under this account, these commands prepare the directory and open the file with Nano:
umask 077
mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
nano "$HOME/.ssh/authorized_keys"
chmod 600 "$HOME/.ssh/authorized_keys"umask 077 limits the default permissions in this shell. mkdir -p creates the folder if it is missing without deleting its contents. The mode 700 reserves the .ssh folder for the account; the mode 600 reserves the file for the owner. In Nano, add the public line copied from PuTTYgen at the end of the file, without deleting existing lines. Save and then exit the editor. If the file already exists, make a backup before modifying it. Do not use a redirection > that would overwrite it.
After editing, still in the target account shell, this command reads the fingerprints of the public keys present in authorized_keys:
ssh-keygen -lf "$HOME/.ssh/authorized_keys" -E sha256Compare the expected fingerprint with the one shown by PuTTYgen and identify the correct entry if the file contains multiple keys. This check is on the authorized user keys, not the fingerprint of the remote machine. Do not remove other keys to simplify comparison.
If the home directory, owners, ACLs, or the key paths are customized, ask the administrator to confirm the configuration. Avoid chmod -R and a blindly applied chown: they can modify unrelated files. From a Linux machine, another method is to install a public key with ssh-copy-id. This command is for a Linux client, not PuTTY under Windows.
Select the PPK in PuTTY and verify authentication
In PuTTY, load the relevant session. Open Connection > SSH > Auth > Credentials, then choose the file in Private key file for authentication. Return to Session and save the configuration. Keep the expected remote account for this session.
Maintain your backup session and open a new PuTTY window for the test. If PuTTY reports an unknown or modified host fingerprint, compare it to a value obtained through a reliable channel before continuing. The private key passphrase may be requested: this does not mean PuTTY is asking for the Linux password.
To confirm the method used, open the Event Log of PuTTY and verify that the expected key is proposed and then accepted for public key authentication. Obtaining a shell alone is not sufficient: Pageant may have supplied another key, and PuTTY may also have another authentication method. To isolate the test, temporarily exit Pageant or remove its keys, then explicitly select the PPK in the session. If PuTTY asks for the Linux password, interrupt this test: a fallback connection does not prove that the key worked. Respect additional factors imposed by the server.
In the shell of the second connection, these commands confirm the account and the machine reached, but not the authentication method:
whoami
hostnameCompare the displayed account with the targeted one and check the expected hostname. The PuTTY Event Log and, if necessary, the server-side logs establish the method employed. Do not close the backup session until the result has been confirmed.
Use Pageant without entrusting it more than necessary
Pageant is optional. Start by successfully testing directly with the PPK. To avoid re-entering the passphrase during subsequent connections, start Pageant, open its window, choose Add Key, and then select the PPK file. Unlock it locally and check the displayed comment or fingerprint. PuTTY can then request the agent to sign the exchanges.
The passphrase protects the file on disk; Pageant facilitates its use as long as the unlocked key remains available in memory. The agent does not install the public key on the server and does not replace the host fingerprint check. Remove Key removes the key from the agent, not from authorized_keys. To revoke access for this machine, separately remove the correct public line on the server from a session still authorized.
Only load useful keys and leave agent forwarding disabled, unless there is a specific need for trusted machines. A malicious process on the machine may attempt to abuse the agent’s signatures. Remove keys from Pageant or close it when they are no longer needed. Never place a passphrase in a shortcut or script.
Diagnose a refusal without weakening the server
- Couldn’t load private key or Unable to use key file: check the file path, its format, and the client version. Properly import the key with PuTTYgen; changing its extension is not sufficient.
- Server refused our key: confirm the remote account, the correspondence between private and public keys, the complete OpenSSH line, the authorized path, and permissions/owners. If you administer the server, check the logs at the precise time of the attempt.
- Too many authentication failures: the agent may be offering too many keys. For a test, select the correct key and remove the others from Pageant. Do not arbitrarily increase
MaxAuthTries. - PuTTY requests a password: distinguish the key passphrase from the Linux password and any potential additional factor. Stop the test if the account password is requested; this is not proof of key authentication.
From an independent console or an existing administrative session, the administrator can check the logging unit present on the distribution. These commands read the last 50 entries of the indicated unit; use the one that exists, often ssh on Debian or Ubuntu, or sshd on other distributions:
sudo journalctl -u ssh -n 50 --no-pager
sudo journalctl -u sshd -n 50 --no-pagerAn empty log does not prove that no attempt has taken place: the distribution may use another unit or a different logging destination. Only share useful lines, having masked infrastructure details. If the configuration uses Match rules or a custom path, have the administrator verify the effective configuration for the concerned account. This article does not request modifying the SSH configuration or disabling a security check.
Do not disable StrictModes, MFA, or host verification to pass the test. Do not allow root as a shortcut and do not reactivate SSH-1 or weak signatures. If the private key or its passphrase is lost, deploy a new pair via a backup access and verify it before removing the old authorization. The final control covers four elements: the correct private file on Windows, the correct public key in the targeted account, the expected permissions, and the acceptance of this key in the PuTTY Event Log.