SSH Key Generator
Generate RSA (2048/4096-bit) key pairs in your browser using Web Crypto API. Keys are generated client-side and never transmitted.
~/.ssh/authorized_keys on your serverPitfalls 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...) thatsshdexpects — 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_keysafter 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.
Why Long-Lived Shared Keys Become a Liability
A shared deploy key — one key pair generated once and distributed to every contractor, script, or team member who needs a given kind of access — is a recurring source of offboarding gaps, and the mechanism is structural rather than accidental. Standard offboarding checklists are built around identity systems: disabling an email account, revoking VPN access tied to SSO, removing someone from a Slack workspace. A shared SSH key doesn't live in any of those systems. It's just a line in an authorized_keys file on however many hosts it was ever added to, with no built-in expiry and no record of who currently holds a copy of the private half — so removing one person's access to everything else in the identity stack does nothing to that key, which keeps working exactly as before.
This is why per-person keys, not per-purpose keys, are the safer default: a key tied to one engineer's identity gets revoked automatically as part of that engineer's offboarding, the same way their SSO account does, instead of requiring someone to remember a manual step for a credential that lives outside the identity system entirely. Pairing that with a hard rotation window — any key not rotated or re-attested within a defined period gets pulled from every host it's authorized on — closes the remaining gap: a credential nobody remembers to revoke eventually expires on its own rather than sitting valid indefinitely.
Practical Scenarios for Generating Keys in a Browser
- 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-keygenbinary 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
What key type should I use — RSA 2048 or RSA 4096?
RSA 4096-bit keys provide a higher security margin and are the recommended choice for keys that will protect long-lived access to important infrastructure. The computational cost of RSA 4096 is higher than 2048-bit, but for interactive SSH sessions this difference is imperceptible. RSA 2048-bit is considered secure by current standards and is appropriate for short-lived keys or high-throughput automation where authentication speed matters. Both options are widely supported by all major SSH servers and Git platforms.
Is it safe to generate SSH keys in a browser?
This tool uses the Web Crypto API, a cryptographically secure subsystem built into modern browsers and subject to the same security review as password managers and online banking applications. Key generation happens entirely in your browser process and no data is transmitted over the network. That said, for the highest-security use cases — keys protecting production databases or root access to critical infrastructure — generating keys directly on the target server or a dedicated air-gapped workstation eliminates any concern about the browser environment.
How do I add my public key to a server or GitHub?
To authenticate with a Linux server, copy the public key text and append it to the file ~/.ssh/authorized_keys on the remote host — one key per line. The ~/.ssh directory must have permissions 700 and authorized_keys must have permissions 600, otherwise the SSH daemon will refuse to use it. You can also use ssh-copy-id -i pubkey.pub user@server if you have temporary password access. For GitHub or GitLab, paste the public key into your account settings under "SSH Keys" — the platform uses it to verify your identity during git clone and git push operations.