How to connect to a Linux VPS over SSH with a PuTTY key
PuTTY is a free SSH client for Windows. This tutorial covers connecting to a Linux VPS from a Windows machine with SSH key authentication instead of a password, from downloading PuTTY to the first successful login. You need the address of the server, an SSH account on it, and an SSH key pair.
Audience level: Beginner
Estimated time: about 20 minutes
End goal: By the end of this tutorial, you log in to your Linux VPS from Windows with PuTTY and an SSH key, without typing an account password.
What SSH and PuTTY do
Secure Shell (SSH) is a network protocol for working on a remote machine across an untrusted network. It encrypts the whole session, identifies the server before you send anything to it, and accepts either a password or a key as proof of who you are. On a Linux VPS the server side of SSH is normally the OpenSSH daemon, listening on TCP port 22.
PuTTY is a free SSH client for Windows and the terminal window you work in once the connection is up. The current release is 0.84. One point saves confusion later: the Windows installer already contains PuTTYgen, the utility that generates and converts keys in this tutorial, so PuTTYgen is never a separate download. The same package also installs the file transfer tools PSCP and PSFTP, the scripting front end Plink, and the authentication agent Pageant.
What you need before connecting
Collect the following before you start:
- The public IP address of the server, written below as <YOUR_SERVER_IP>
- The SSH account name on the server, written below as <YOUR_USERNAME>
- The SSH port, which is 22 unless your provider or your own configuration uses another one
- Your private key file on the Windows machine, either in PuTTY format (.ppk) or in OpenSSH format
- PuTTY 0.84 on Windows 10, Windows 11, Windows Server 2022, or Windows Server 2025. Installation is covered in the next section
- A Linux VPS running the OpenSSH server and reachable over the network. The server side commands below apply to Ubuntu 24.04 LTS and 26.04 LTS, Debian 12 and 13, AlmaLinux 9 and 10, and other distributions that use OpenSSH
- One working way in, if the public key is not on the server yet: a password session, another key, or the console in your provider's panel
- About 20 minutes, and no knowledge beyond basic use of a Linux shell
A key pair has two halves with different jobs. The private key stays on your Windows machine and produces the proof of your identity. The public key sits on the server inside the account you log in to, and lets the server check that proof.
Never upload, mail, or paste the private key to the server or to any other machine. Only the public key leaves your computer. A private key file that reaches a place you do not control counts as compromised, and the correct response is to replace the pair.
Installing PuTTY
Download PuTTY only from the project itself. putty.software is the short official domain of the project and redirects to the download pages of the author on chiark.greenend.org.uk.
Warning putty.org and puttygen.com are not project sites and are not maintained by the PuTTY team. Nothing guarantees that files served from those addresses are the software the authors released.
Take the Windows MSI installer that matches your architecture. The 64-bit x86 build, putty-64bit-0.84-installer.msi, fits almost every current machine. The 32-bit x86 build exists for old hardware and old Windows versions, and a separate Arm64 build covers Windows devices with Arm processors.
Run the downloaded .msi file. Click Next on the welcome page, keep the default destination folder, keep the default set of features, and click Install. Approve the Windows administrator prompt if one appears, then close the wizard with Finish.
The Start menu now holds entries for PuTTY and PuTTYgen, and the utilities listed earlier are installed alongside them.
The project also publishes the current installers in the Microsoft Store, usually a few days after a release. Both sources deliver the same build.
Check or convert your SSH key
PuTTY reads private keys in its own format, the .ppk file. What happens next depends on what you already have.
If you already have a .ppk file
Nothing needs converting. Note the location of the file on disk and continue with the PuTTY configuration below.
If your key is in OpenSSH format
Keys produced by ssh-keygen carry names such as id_rsa or id_ed25519, usually with no extension, and PuTTY does not read them directly. Convert such a key once and use the result from then on.
Start PuTTYgen and click Load. The file dialog opens with its filter set to PuTTY private key files, which hides every file that does not end in .ppk, so switch the filter to All Files before you go looking for the key. Select the private key file and enter its passphrase if it has one. PuTTYgen reports that the key is not in its native format and loads it anyway. Click Save private key, name the file, and keep the .ppk extension. The passphrase carries over unchanged unless you deliberately type a new one.
The Conversions menu offers the same operation as an explicit Import key command. Either route produces the same .ppk file.
If you do not have a key yet
Generate a pair in PuTTYgen. Leave the key type at RSA with 2048 bits or more, or select EdDSA with 255 bits for an Ed25519 key, then press Generate. Move the mouse pointer across the blank area of the window until the progress bar fills, because PuTTYgen collects randomness from that movement. Once the key appears, type a passphrase into Key passphrase, repeat it in Confirm passphrase, and save both halves with Save public key and Save private key.
PuTTY works with RSA and Ed25519 keys, and also with ECDSA and DSA. The screenshots in this tutorial show an RSA key. For a new pair on current systems, Ed25519 is a good default.
Add the public key to the server
Skip this section if your provider already placed the key in the account, or if the pair was created for this server. Otherwise you need one working way in: a password session, another key, or the provider console.
Open a session as the account that will use the key, and prepare the directory:
mkdir -p ~/.ssh chmod 700 ~/.ssh touch ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys chown -R <YOUR_USERNAME>:<YOUR_USERNAME> ~/.ssh
The commands create ~/.ssh and an empty authorized_keys if either is missing, then set the ownership and the permissions OpenSSH requires. For an ordinary account such as admin or ubuntu the full path is /home/
Open the file for editing:
nano ~/.ssh/authorized_keys
Switch to the PuTTYgen window, select the entire contents of the box labeled Public key for pasting into OpenSSH authorized_keys file, and copy it. Back in the terminal, paste it as the last line of the file. A right click pastes the clipboard into a PuTTY window. Save the file and close the editor.
The public key occupies exactly one line, from ssh-rsa or ssh-ed25519 through to the end of the key comment. Do not split it, do not let the editor wrap it, and do not add any comment text of your own on that line. A key broken across lines, or followed by stray characters, is rejected, and the server reports nothing more informative than a refused key.
The file now holds one line per authorized key, and any lines that were already there stay as they are.
Configure PuTTY
Start PuTTY. The Session panel opens first. Type the address of the server into Host Name (or IP address), set Port to 22 or to the port your server listens on, and leave Connection type on SSH.
Now point PuTTY at the private key. In the tree on the left, open Connection, then SSH, then Auth, then Credentials, and use Browse next to Private key file for authentication to select your .ppk file. That tree differs slightly between PuTTY versions, and older releases keep the field on the Auth panel itself, so navigate by the name of the field rather than by the exact path.
Saving the session repays the few extra seconds. Return to Session, type a name into Saved Sessions, and click Save. The name appears in the list, and selecting it and clicking Load restores the address, the port, and the path to the key.
Connect and log in
Click Open. On a first connection to a server PuTTY has not seen before, it stops and presents the host key of that server:
The host key is not cached for this server: <YOUR_SERVER_IP> (port 22) The server's ssh-ed25519 key fingerprint is: ssh-ed25519 255 SHA256:<FINGERPRINT_STRING>
Compare the fingerprint with the one your provider published for the server. More info... shows the full public key if that is easier to compare. When the fingerprint matches, click Accept: PuTTY caches the key, the connection continues, and the question does not come back for that host. Connect Once connects without caching anything. Cancel abandons the connection, which is the right choice when the fingerprint matches nothing you expect.
A host key warning on a later connection to the same server, in the stronger wording about a potential security breach, means the server presented a different key than before. A rebuilt server does that legitimately. So does an attacker who has redirected your connection. Establish which of the two applies before you type anything into the window.
Once the host key is settled, the terminal shows the login prompt:
login as:
Type the account name and press Enter. PuTTY then uses the key you configured. If the key carries a passphrase, PuTTY asks for it in the same window, and the characters stay invisible as you type.
Three things are easy to confuse at this point:
- The account name identifies the user on the server, root or a regular account such as admin.
- The key passphrase decrypts the private key file on your own machine, and the server never sees it.
- The account password belongs to the server account. With key authentication working, you do not need it in order to log in.
Confirm that key authentication works
The missing password prompt is the confirmation. If the session opens after the key passphrase, or with no prompt at all, the server accepted the key. Two commands state the result plainly:
whoami hostname
Expected output:
admin vps-01
The first line names the account the session runs as, and it has to match the account whose authorized_keys file holds the public key. The second names the server.
Troubleshooting
| Problem | Cause | Solution |
|---|---|---|
| Server refused our key | The public key is not installed correctly for that account | Check that ~/.ssh/authorized_keys holds the key on a single line, that ~/.ssh is 700 and authorized_keys is 600, and that both belong to the account |
| No supported authentication methods available | PuTTY has no key to offer, and the server does not accept passwords | Set the .ppk file under Connection, SSH, Auth, Credentials |
| Access denied | The account name is wrong | Confirm the account name on the server. PuTTY cannot correct a mistyped name in the same session, so close the window and connect again |
| Network error: Connection timed out | The address or port is wrong, or a firewall drops the traffic | Verify the IP address and the port, then check the firewall on the server and along the path |
| Network error: Connection refused | Nothing listens on that port, because the SSH service is stopped or bound to a different port | Check the state of the SSH service and the port it listens on, through the provider console if you have no other access |
| The passphrase is rejected | The passphrase of the private key is wrong | Type it again. If it keeps failing, use a key whose passphrase you know, or generate a new pair |
| The key works in another client but not in PuTTY | The key is in OpenSSH format rather than .ppk | Convert it in PuTTYgen as described above |
SSH key security
- Keep the private key on your own machine and share it with nobody. Anyone holding that file can log in as you.
- Protect the key with a passphrase, and choose one you do not use anywhere else.
- Store the key file where only your account can read it, and include it in your personal backups. A lost private key cannot be recovered from the public half.
- Use separate keys for separate servers or roles where that is practical, so that one exposed key does not open everything.
- Treat any suspected exposure as a real one: generate a new pair, install the new public key, and remove the old line from authorized_keys on every server.
Once key authentication works reliably, two server side changes reduce your exposure further: disable password authentication in the OpenSSH configuration, and restrict the SSH port in the firewall to the addresses you connect from.
Reverting the changes
To remove the key from the server, keep a copy of the file first, then delete the line that holds the public key:
cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak nano ~/.ssh/authorized_keys
Confirm that another way in still works before you remove a key. An account left with no usable key and no password login needs the provider console to recover.
To remove PuTTY from Windows, clear its stored settings first, because uninstalling the program leaves them behind. Run the following in a command prompt or in the Run dialog, and confirm the prompt that appears:
putty.exe -cleanup
Then open Settings, go to Apps, then Installed apps, find PuTTY in the list, and choose Uninstall. Delete the .ppk file yourself if you no longer need the key.
Conclusion and next steps
Your Windows machine now reaches the Linux VPS through PuTTY with a key instead of a password, the session is saved for reuse, and the host key of the server is cached and verified. Password authentication on the server can now be switched off, which removes the most heavily attacked way into a public facing machine. Pageant, installed alongside PuTTY, holds the decrypted key for the length of a Windows session and spares you the passphrase on every connection. For related tasks, see Connecting via SSH for password based access, Changing the SSH port for moving the service off port 22, and Connecting to a server via SSH on MacOS for the same task from macOS.
Document Version: 1.0
Last Updated: August 2026
Owner: Technical Documentation Team
