SSH Key Generator
Generate secure SSH private and public keys client-side.
SSH Key Generator
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The SSH Key Generator produces an SSH key pair — a public key you install on servers you want to access and a private key you keep secret and use to authenticate — in the algorithm and size of your choosing. SSH key authentication replaces password-based login with something dramatically stronger: proving possession of a private key cryptographically, rather than transmitting a shared secret that could be guessed, phished, or reused across services.
- This tool supports the two algorithm families in common current use: RSA (offered here at 2048 and 4096-bit sizes, the traditional default with the broadest legacy compatibility) and Ed25519 (a modern elliptic-curve signature scheme, defined by RFC 8032 and adopted for SSH by RFC 8709), which produces much smaller keys and signatures than RSA while offering comparable or stronger security and faster operations.
- The private key this tool outputs uses OpenSSH's own private key format (headers read -----BEGIN OPENSSH PRIVATE KEY-----) — a format OpenSSH itself documents (not an IETF RFC), distinct from the PKCS#1/PKCS#8 formats used for TLS private keys, and required specifically for Ed25519 keys, which the older PEM-based SSH key formats can't represent.
How It Works
- You choose a key type — RSA-2048, RSA-4096, or ED25519 — trading off between RSA's broader legacy tool compatibility and Ed25519's smaller size and faster operations.
- A key pair is generated locally: a private key that must be kept secret, and a public key meant to be installed on any server or service you want to authenticate to.
- The public key is formatted as a single line: an algorithm prefix (ssh-rsa or ssh-ed25519), a base64-encoded body containing the key's actual parameters, and an optional comment.
- The private key is output in OpenSSH's own private key format, the format required for Ed25519 keys and now the default OpenSSH itself generates for RSA keys as well.
Usage
- Choose a key type — RSA-2048, RSA-4096, or ED25519.
- Generate the key pair.
- Install the public key on any server or service you want to authenticate to (typically by appending it to that account's authorized_keys file).
- Keep the private key secret and use it with your SSH client to authenticate — never share it or upload it anywhere the public key alone would suffice.
Examples
- Generating an Ed25519 key pair for a new server, to benefit from its smaller key size and faster signing compared to RSA, where the server's SSH version supports it (virtually all current versions do).
- Generating a dedicated RSA-4096 key pair for a specific automated deployment pipeline, kept separate from any personal SSH key used for interactive server access.
- Creating a test key pair to verify a CI system correctly authenticates via SSH key before wiring up real production credentials.
- Generating an RSA-2048 key pair specifically for compatibility with an older system that doesn't yet support Ed25519 keys.
Real-World Use Cases
- Generating a new SSH key pair for accessing a server, to install the public half in the server's authorized_keys file and keep the private half on your own machine.
- Creating a dedicated key pair per service or automation task, rather than reusing one key everywhere, to limit the impact if any single key is ever compromised.
- Testing how a specific key type (RSA versus Ed25519) behaves with a given tool or service before standardizing on it for real infrastructure access.
- Producing a throwaway key pair for local development or CI testing environments that need SSH access without touching your own personal or production keys.
Best Practices
- Prefer Ed25519 for new keys where compatibility allows — it offers strong security with a much smaller key size and faster operations than RSA, and virtually all current SSH implementations support it.
- Generate a separate key pair per distinct use case (personal access, a specific automation pipeline, a specific server group) rather than reusing one key everywhere, so revoking one doesn't require rotating unrelated access.
- Protect a generated private key with a passphrase wherever your workflow can accommodate entering it, adding a second factor beyond simple file possession.
- Never place a private key in a location a server, CI system, or third-party tool doesn't strictly need it — only the public key needs to be distributed to systems you're authenticating to.
Common Mistakes
- Using RSA-2048 or smaller purely out of habit when Ed25519 would offer better security and performance and is supported by virtually every current SSH client and server.
- Reusing a single personal SSH key across every server and automation task, meaning a single leaked key compromises access everywhere it's installed.
- Confusing the public key (safe to install anywhere) with the private key (must never be shared) and accidentally distributing the wrong file.
- Generating a key pair without a passphrase for a key that will be used interactively, missing an easy additional layer of protection against a stolen key file being immediately usable.
Limitations
- This tool generates SSH key pairs for testing and prototyping in your browser; treat any private key generated here as a test artifact, not a production credential, unless generated and used entirely within a fully trusted, controlled environment.
- It does not install the public key on any server for you — that step (appending it to the target account's authorized_keys file) happens outside this tool.
- Generated keys exist only in local browser memory during the session and are not persisted — copy both keys before reloading the page.
Technical Reference Guide
- The SSH public key file format (the algorithm-prefixed, base64-encoded line format) is defined by RFC 4253, Section 6.6.
- The Ed25519 signature algorithm itself is defined by RFC 8032; its specific use within the SSH protocol is defined by RFC 8709.
- The OpenSSH private key format this tool outputs (required for Ed25519 keys, and now OpenSSH's default for RSA as well) is documented in OpenSSH's own PROTOCOL.key file rather than a dedicated IETF RFC.
FAQ
Should I choose RSA or Ed25519 for a new SSH key?
Ed25519 is generally preferable for new keys — it's smaller, faster, and considered at least as secure as RSA-4096, with broad support in virtually all current SSH implementations. Choose RSA only if you specifically need compatibility with older systems that don't yet support Ed25519.
What's the difference between the public and private key this tool generates?
The public key is meant to be installed on servers you want to access (in an authorized_keys file) and is safe to share freely. The private key must be kept secret — it's what actually proves your identity during authentication, and anyone who has it can authenticate as you.
Why is the private key in a different format than a TLS private key?
SSH uses its own private key format, OpenSSH's own documented structure, distinct from the PKCS#1/PKCS#8 formats used for TLS. This format is required for Ed25519 keys, which the older formats can't represent, and OpenSSH now defaults to it for RSA keys too.
Do I need a different key for every server I connect to?
Not strictly, but it's better practice to use a distinct key per use case (personal access, a specific automation pipeline) so that revoking access for one purpose doesn't require rotating a key used everywhere else.
Should I add a passphrase to my SSH private key?
Yes, wherever your workflow can accommodate entering it — a passphrase adds a second factor, so a stolen key file alone isn't immediately usable without also knowing the passphrase.
Can I recover my private key if I lose it?
No — if a private key is lost, it cannot be regenerated from the public key. You'd need to generate a new key pair and update the public key on every server or service where the old one was installed.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools