PPK to PEM Converter

Absolutely. This tool is specifically designed with security as the top priority. Unlike many online converters that upload your data to servers, our converter performs 100% client-side processing—all conversion happens directly in your web browser using JavaScript. Your private key never leaves your computer or travels over the internet. You can verify this by opening your browser's developer tools (F12) and checking the Network tab during conversion—you'll see zero network requests. For maximum security-conscious users, you can even save this webpage locally and use it offline. The source code is visible, transparent, and can be audited. That said, if your security policy prohibits any web-based tool usage, consider using PuTTYgen's built-in export feature or command-line tools like ssh-keygen for conversion.

While this tool specializes in PPK-to-PEM conversion (the most common direction), converting PEM back to PPK is absolutely possible using PuTTYgen, PuTTY's key generator tool. Open PuTTYgen, go to Conversions → Import Key, select your PEM file, enter the passphrase if it's encrypted, then click "Save private key" to export as PPK format. This is useful when you have PEM keys (perhaps generated with ssh-keygen on Linux) but need to use them with PuTTY on Windows. PuTTYgen can handle RSA, DSA, ECDSA, and Ed25519 keys in PEM format. Note that for ongoing work, most modern tools including recent PuTTY versions can directly use PEM keys, so converting to PPK is becoming less necessary unless you're using older software.

PPK-2 (PuTTY-User-Key-File-2) was the standard format for years, while PPK-3 (PuTTY-User-Key-File-3) is a newer format introduced in PuTTY 0.75 (2021) with improved security. The main differences: PPK-3 uses Argon2 for key derivation instead of SHA-1, providing better protection against brute-force attacks on encrypted keys. It also defaults to stronger encryption (AES-256-CBC instead of AES-256-CFB). PPK-3 stores additional metadata and uses a more robust MAC algorithm. Our converter supports both formats seamlessly—the resulting PEM format is identical regardless of which PPK version you start with. If you're generating new keys, use modern PuTTY versions to create PPK-3 format for better security. Older PuTTY versions (pre-0.75) can't read PPK-3 files, so if you need backward compatibility, explicitly choose PPK-2 when saving in PuTTYgen.

Several issues could cause PEM key authentication failures. First, verify file permissions—on Unix systems, private keys must have 600 permissions (readable/writable only by owner). SSH will refuse to use keys with looser permissions as a security measure. Use `chmod 600 /path/to/key.pem` to fix this. Second, ensure the corresponding public key is correctly installed on the server in ~/.ssh/authorized_keys with proper permissions (700 for ~/.ssh directory, 600 for authorized_keys file). Third, check that you're using the correct username—cloud providers use specific usernames like "ubuntu" for Ubuntu instances or "ec2-user" for Amazon Linux. Fourth, verify the key type is supported—very old SSH servers might not support ECDSA or Ed25519 keys. Finally, check SSH daemon configuration on the server (/etc/ssh/sshd_config) to ensure PubkeyAuthentication is enabled. Use `ssh -v` for verbose output to see exactly where authentication fails.

Our converter can parse the structure of encrypted PPK files and will identify them as password-protected, but it cannot decrypt them without the passphrase. This is by design—requiring the passphrase in a web tool would introduce security concerns about how passphrases are handled. For encrypted keys, you have two options: First, use PuTTYgen to load your encrypted PPK (it will prompt for the passphrase), then export it as OpenSSH format which produces a PEM file. Second, temporarily decrypt the key by loading it in PuTTYgen and saving as an unencrypted PPK (select "No" when asked about passphrase protection), convert it using our tool, then delete the unencrypted version. We recommend the first approach as it never creates an unencrypted private key file. Note that the resulting PEM file can also be encrypted—when saving from PuTTYgen to OpenSSH format, you can choose to protect it with a passphrase.

SSH key pairs consist of two mathematically related but distinct files: the private key (which you're converting from PPK to PEM) and the public key. The private key is secret—like a password—and must never be shared or exposed. It stays on your local computer and proves your identity. The public key, on the other hand, is designed to be shared freely—you place copies on every server you want to access, typically in ~/.ssh/authorized_keys. The cryptographic magic is that data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. When you SSH to a server, your SSH client uses your private key to prove you possess the private key matching the public key the server has on file, without ever transmitting the private key itself. This asymmetric encryption is why SSH keys are more secure than passwords—the secret (private key) never travels over the network, so it can't be intercepted.

You only need to convert the private key from PPK to PEM. Public keys have a different, simpler format that's already compatible across systems. When you generate a key pair in PuTTYgen, you get a .ppk file (private key) and PuTTYgen displays the public key in the "Public key for pasting into OpenSSH authorized_keys file" box. This public key text starts with "ssh-rsa" or similar and is identical whether you're using PuTTY or OpenSSH—no conversion needed. Simply copy this public key text and paste it into ~/.ssh/authorized_keys on your servers. If you only have the PPK private key and need to extract the public key later, you can load the PPK into PuTTYgen and it will display the public key, or use ssh-keygen on Linux: `ssh-keygen -y -f converted_key.pem > public_key.pub` to extract the public key from your converted PEM private key.

Using converted PEM keys with Git hosting services is straightforward but requires a few steps. First, extract the public key from your converted PEM private key using: `ssh-keygen -y -f converted_key.pem > github_key.pub`. Then, copy the contents of github_key.pub and add it to your GitHub/GitLab account in Settings → SSH and GPG keys → New SSH key. For the private key setup, save your converted PEM file to ~/.ssh/ with a descriptive name like `~/.ssh/github_key.pem` and set permissions with `chmod 600 ~/.ssh/github_key.pem`. Configure Git to use this key by adding to ~/.ssh/config: "Host github.com / IdentityFile ~/.ssh/github_key.pem". Now Git operations (clone, push, pull) will automatically use this key. For multiple Git accounts (work and personal), use different Host aliases in the SSH config and specify the appropriate host in your Git URLs.

If you believe your private key has been compromised or exposed, act immediately to minimize potential damage. First, access every server that has the corresponding public key and remove it from ~/.ssh/authorized_keys—this prevents the compromised key from being used for authentication. If you manage many servers, use configuration management tools (Ansible, Chef, Puppet) to remove the public key across all systems simultaneously. Second, if the key was used for cloud services (AWS, GCP, Azure), log into each console and delete the key from the SSH keys management section. Third, review access logs on affected servers (/var/log/auth.log on Linux) for any suspicious login activity around the time of suspected compromise. Fourth, generate a new, completely fresh key pair—don't just change the passphrase on the compromised key, generate new keys from scratch. Finally, deploy the new public key to all servers and services, verify it works, then securely delete all copies of the compromised private key. Going forward, use passphrase-protected keys and consider hardware security keys (like YubiKey) for highly sensitive access.

While technically you can use a single SSH key pair for everything, security best practices recommend using different keys for different purposes. Using one key for all servers creates a single point of failure—if that key is compromised, attackers gain access to everything. Instead, consider a tiered approach: generate one key for production servers, another for development/staging, another for personal projects, and yet another for Git hosting services. This limits the blast radius if one key is compromised. Additionally, different keys make it easier to rotate credentials—when leaving a job, you only need to regenerate and update work-related keys, leaving personal keys intact. Modern SSH clients can manage many keys effortlessly using ssh-agent and SSH config files with Host-specific IdentityFile directives. The small inconvenience of managing multiple keys is vastly outweighed by the security benefits. If you must use one key for convenience, at minimum separate your most critical production access from everything else.