Security

SSH Key Passphrase Generator

Generate strong passphrases for SSH private keys. Protect your server access with a secure passphrase. Free, browser-based, no data stored.

About this ssh key passphrase generator

An SSH key passphrase encrypts your private key file — if someone steals the file (from a backup, a compromised laptop, or a stolen drive), they cannot use it without the passphrase. Without a passphrase, anyone with your private key file has instant access to every server it is authorized for. The passphrase should be long enough to resist offline brute-force attacks against the key file encryption (typically AES-128 or AES-256). Since you type this passphrase whenever you load the key (unless using an SSH agent), it needs to be both strong and typeable. This generator defaults to 20 characters with letters and numbers — a practical balance between security and the frequent typing required. If you use an SSH agent that caches the unlocked key, you can use a longer, more complex passphrase since you only type it once per session.

How SSH key encryption works

When you generate an SSH key pair, you get two files: a public key (safe to share) and a private key (never shared). The private key file is what the passphrase protects. Without a passphrase, the private key is stored in plain text on disk — anyone with read access to the file can use it immediately. With a passphrase, the private key is encrypted using a key derived from the passphrase via a key derivation function (PBKDF2 or bcrypt depending on the key format). The OpenSSH format introduced in OpenSSH 6.5 uses bcrypt with a configurable round count (default 16) to derive the encryption key, making offline brute-force attacks significantly more expensive than older PEM-format keys. When you authenticate to a server, your SSH client decrypts the private key in memory using your passphrase, performs the cryptographic handshake, and then discards the decrypted key — the passphrase is never transmitted.

Using ssh-agent to manage passphrase unlocking

Typing your SSH passphrase on every connection is impractical for engineers who make dozens of connections per day. The ssh-agent daemon solves this by caching the decrypted private key in memory for the duration of a session. You unlock the key once with `ssh-add ~/.ssh/id_ed25519` and your passphrase, and subsequent SSH connections use the cached key without prompting. The agent never writes the decrypted key to disk and never exposes it to other processes — communication happens through a Unix socket. On macOS, the system Keychain integration (`ssh-add --apple-use-keychain`) persists the passphrase across reboots, so the key is automatically loaded when you log in. On Linux, you can start ssh-agent in your shell profile and add keys automatically. For servers or automation contexts, avoid storing passphrases in scripts — use agent forwarding or certificate-based authentication instead.

SSH key security in team and cloud environments

SSH keys in team environments require careful lifecycle management. Every developer should have their own key pair — shared SSH keys make it impossible to audit who accessed what, and removing one person's access requires rotating the shared key for everyone. For cloud instances (AWS EC2, GCP, DigitalOcean), use the cloud provider's key management features rather than manually distributing public keys. Consider using SSH certificates instead of raw public keys for larger teams: a certificate authority signs developer keys with an expiry date, so access automatically expires without requiring changes to each server's authorized_keys file. Store SSH private keys only on the machine where they are used — avoid copying private keys to shared drives, cloud storage, or CI/CD environment variables. For automated deployment pipelines, use deploy keys (separate key pairs with read-only access to specific repositories) rather than personal keys.

Choosing the right SSH key type and length

The SSH protocol supports several key algorithms, each with different security and compatibility trade-offs. Ed25519 is the recommended choice for all new keys: it uses elliptic curve cryptography on Curve25519, offers 128-bit equivalent security, generates small keys (68 bytes for the public key), and is supported by all modern SSH implementations. RSA is still widely used and compatible with legacy systems — use 4096-bit keys if you must use RSA; avoid 1024-bit and 2048-bit keys which are increasingly considered marginal. ECDSA using NIST curves (P-256, P-384) is supported but has raised concerns about potential backdoors in the curve parameters — prefer Ed25519 when possible. DSA keys are limited to 1024 bits by the standard and are disabled in OpenSSH 7.0 and later. The passphrase you choose protects whatever key type you use — a strong passphrase on an Ed25519 key is more secure than a weak passphrase on RSA-4096.

FAQ

Common questions

Do I really need a passphrase on my SSH key?

Yes. An unprotected private key is equivalent to writing your password in a plain text file. Anyone who obtains the file — through a backup breach, stolen laptop, or malware — has full access to your servers.

How long should an SSH passphrase be?

At least 16-20 characters. The passphrase protects against offline attacks on the key file, so it needs to be strong enough to resist GPU-accelerated cracking. 20 characters with mixed types provides ~119-131 bits of entropy.

Can I use an SSH agent to avoid typing it repeatedly?

Yes. ssh-agent caches the decrypted key in memory for the duration of your session. You type the passphrase once when loading the key, then connect to servers without re-entering it. On macOS, the Keychain can store it permanently.

What if I forget my SSH passphrase?

There is no recovery mechanism — the passphrase is the encryption key for the private key file. You would need to generate a new SSH key pair and add the new public key to your servers. Store the passphrase in a password manager as backup.

Should I use symbols in my SSH passphrase?

Only if you are comfortable typing them accurately. Symbols increase entropy per character but also increase the chance of typos under pressure (e.g., when logging in to a production server during an incident). A longer alphanumeric passphrase is equally strong and more reliable to type.

What key type should I generate alongside the passphrase?

Use Ed25519 for new keys — it is faster, smaller, and considered more secure than RSA-2048. If compatibility with older systems is required, RSA-4096 is acceptable. Avoid DSA and ECDSA with NIST curves where possible.

Can I add a passphrase to an existing SSH key without regenerating it?

Yes. Run `ssh-keygen -p -f ~/.ssh/id_ed25519` (replace with your key path). You will be prompted for the current passphrase (or none) and then the new one. The key pair itself does not change — only the local encryption of the private key file.

How do I rotate an SSH passphrase if I suspect it was compromised?

Run `ssh-keygen -p` to change the passphrase immediately. If you suspect the private key file itself was copied, generate a completely new key pair and remove the old public key from all `~/.ssh/authorized_keys` files on your servers.