In this guide
Public and private keys have different jobs
Your private key stays under your control and proves your identity. The public key is placed on authorized servers. The public key cannot normally be used to reconstruct the private key.
Treat a private key like a high-value credential: restrict access to the file, use a strong passphrase where interactive use permits it, and never email or paste it into tickets or chat.
Generate a key with PuTTYgen
Choose an approved key type
Ed25519 is a common modern choice when all target systems support it. Follow organizational standards where they specify another type.
Generate the key pair
In PuTTYgen, choose the approved key type and select Generate. Move the pointer over the blank area while PuTTYgen gathers randomness if the current version requests it. Generation creates the matching public and private parts locally.
Add a useful comment
Identify the owner and purpose without putting confidential data in the comment.
Set a passphrase
Use a unique passphrase and an approved password manager. Avoid passphrase-free interactive keys.
Copy the OpenSSH public key
For an OpenSSH server, copy the complete single-line value from “Public key for pasting into OpenSSH authorized_keys file.” This text is public, but its owner and purpose should still be handled according to organizational policy.
Save the private key
Select Save private key and store the PPK file in an approved protected location. The private key must remain with its owner or authorized workload; never paste it into a website, ticket, email, or chat.
Install the public key on a server
On an OpenSSH server, an authorized administrator typically places the copied single-line public key in the target account’s ~/.ssh/authorized_keys file. Each key occupies its own line. A common permission baseline is 700 for the ~/.ssh directory and 600 for authorized_keys, although the server’s platform and policy remain authoritative.
PuTTYgen’s Save public key command can create a public-key file in a different format. For OpenSSH authorized_keys, use the text specifically labeled for pasting into authorized_keys unless the provisioning system requests another format.
Use an approved provisioning process where available instead of making undocumented manual edits. Installing the public key does not require uploading or disclosing the private PPK file.
A key should map to one person or one narrowly defined workload. Shared private keys make accountability and revocation difficult.
Use Pageant carefully
Pageant can hold unlocked private keys in memory so PuTTY sessions can authenticate without repeated passphrase prompts. Load only the keys needed for the current work, lock your workstation, and remove keys when finished. Avoid agent forwarding unless the workflow has been reviewed.
Plan the complete key lifecycle
- Inventory the owner, purpose, systems, creation date, and review date.
- Remove access when a person changes roles or leaves.
- Rotate keys after suspected exposure and according to policy.
- Prefer separate keys for materially different environments.
- Test revocation and emergency replacement before an incident.
- Never commit private keys to source control.