SSH Key Generator

Pitfalls That Trip Up Even Experienced Engineers

• Treating the on-screen private key as safely stored: the moment you close or refresh this tab, the key is gone — copy it into a password manager or a properly permissioned file on disk immediately, rather than leaving it sitting in a browser tab or clipboard history, which is the difference between a usable key and a lost one.
• Expecting the PEM public key to paste straight into authorized_keys: this tool exports keys in generic SPKI/PKCS#8 PEM format (the same wrapper used for TLS certificates), not the single-line OpenSSH wire format (ssh-rsa AAAAB3NzaC1yc2EA...) that sshd expects — check what format your target server actually requires before assuming a direct paste will work.
• Reusing one key pair across every server, laptop, and CI job: a single leaked or over-shared key then grants access to everything it was ever added to; generating separate keys per system or per purpose keeps a compromise contained.
• Leaving orphaned keys in authorized_keys after someone leaves the team: unlike a shared password, an SSH public key doesn't expire on its own — if it isn't manually removed from every host it was added to, it keeps working indefinitely.

A Cautionary Tale: The Shared Deploy Key

A mid-size engineering team once generated a single SSH key pair for "deployments" and distributed the private half to every contractor who touched the release pipeline over two years, storing it in a shared password vault entry that nobody thought to rotate. When the contract with one contractor ended, the offboarding checklist covered email, Slack, and VPN access — but nobody remembered that the same key was still sitting in that vault entry, still valid, still listed in the authorized_keys file of a dozen production hosts. Nine months later, a routine access audit turned up SSH logins from an IP range that didn't match any current employee, traced back to the same never-rotated key.

Nothing had actually been exfiltrated, but the incident review concluded that a single long-lived, widely shared key with no expiry and no per-person attribution had turned what should have been a two-minute offboarding step into a months-long blind spot. The fix was mundane but effective: one key per engineer, keys tied to an identity in the access-review system, and a hard rule that any key not rotated within a defined window gets pulled from every host automatically.

Where Browser-Generated Keys Fit Into Your Workflow

• Provisioning a brand-new server or VM: generate a pair here and paste the public half into your cloud provider's instance-creation wizard (AWS EC2 key pairs, the metadata field on GCP/Azure VMs) before the machine even boots.
• Authenticating to GitHub or GitLab over SSH: generate a pair dedicated to Git operations and register only the public key with your account, keeping it separate from keys used for server access.
• Working from a locked-down or unfamiliar machine: on a Chromebook, a shared jump box, or any environment without a terminal or the ssh-keygen binary installed, this tool gives you a working key pair without needing to install anything.
• Spinning up a short-lived key for a one-off task: a temporary support session or a single scripted migration that needs its own credential, used once and then removed from the target's authorized_keys.

Wiring Key Generation Into Automated Pipelines

Production CI/CD systems rarely generate SSH keys through a browser — instead they call ssh-keygen or an equivalent library programmatically as part of pipeline bootstrap, then store the private half as an encrypted secret in the CI platform (GitHub Actions secrets, GitLab CI/CD variables, or a dedicated secrets manager like Vault or AWS Secrets Manager) rather than committing it anywhere. A typical deploy pipeline injects that secret into an ephemeral ssh-agent at job start, uses it to authenticate against the target hosts, and lets the agent's in-memory storage disappear when the job finishes — the key material never touches the runner's disk.

Best practice layers on top of this: scope each CI deploy key to a single repository or a single environment using GitHub's per-repository deploy keys or a forced-command restriction in authorized_keys (command="/opt/deploy.sh" ssh-rsa AAAA...), so a compromised pipeline credential can only run the one action it was issued for. This browser tool is a reasonable stand-in when you need to generate a one-off key by hand to test a pipeline's authentication step locally, but the production path should always generate, store, and rotate keys through infrastructure your CI system controls directly.

Frequently Asked Questions