Creating RSA keys to enable SSH access relies on a public-key authentication handshake where the server holds a public key and the client proves possession of the matching private key. The RSA Key Generator produces a valid RSA key pair, but the format it exports is RSA-OAEP wrapped in standard PEM envelopes, not the OpenSSH line format that sshd and ssh-keygen expect. That distinction matters because enabling SSH access requires not just any RSA pair but specifically an RSA key encoded in the format the OpenSSH implementation reads. The browser tool solves the harder cryptographic half of the problem: it generates a fresh 2048- or 3072-bit RSA modulus, exponent 65537, and SHA-256 OAEP parameters, then exports the public half as SubjectPublicKeyInfo (SPKI) PEM and the private half as unencrypted PKCS#8 PEM. The bridge to SSH usually means converting those envelopes to OpenSSH format with another utility, or generating the SSH key directly with ssh-keygen on the system that needs to authenticate. RSA Key Generator is useful when you want a verifiable RSA-OAEP pair in your browser with no server upload, and when you want to understand the underlying math before committing a private key to a long-lived secret store.
What Enabling SSH Access Actually Requires
SSH public-key authentication uses an asymmetric pair, but the wire and storage format is OpenSSH's own line-oriented representation rather than generic PEM. A typical authorized_keys line begins with the algorithm tag, such as ssh-rsa or rsa-sha2-256, followed by Base64-encoded key material and an optional comment. The private side is stored either as an OpenSSH private key (a file that starts with -----BEGIN OPENSSH PRIVATE KEY-----) or in the older PEM form that ssh-keygen -m PEM can produce on systems where the OpenSSH format is not yet supported.
The math underneath is still RSA, with a modulus that today's servers expect to be at least 2048 bits. The OpenSSH wire format encodes the modulus and the public exponent, and the private key adds d, p, q and the CRT parameters used to speed up signing. None of those bytes look like the PEM envelopes the browser RSA Key Generator emits, which is why a freshly generated SPKI/PKCS#8 pair is not a drop-in replacement for an authorized_keys entry.
What the browser tool does give you is the standard ASN.1 envelopes described by RFC 7468 for the wrapping and RFC 8017 for the underlying RSA primitives. That foundation is portable across TLS libraries, Java's KeyFactory, Python's cryptography package, and most HSM vendor SDKs that read PEM directly.
What RSA Key Generator Produces in Your Browser
RSA Key Generator is a single-page utility that asks the platform Web Cryptography implementation to generateKey for RSA-OAEP with SHA-256, modulus length 2048 or 3072, and the fixed public exponent 65537. Generation is asynchronous; the larger 3072-bit modulus takes noticeably longer because the browser has to find two large primes of the right size and then run an extended Euclidean step to derive the private exponent.
Once generation finishes, the public key is exported as DER, Base64-wrapped at 64 columns, and labeled BEGIN PUBLIC KEY — that is the SubjectPublicKeyInfo structure from X.509. The private key is exported as PKCS#8 DER and labeled BEGIN PRIVATE KEY, without any password envelope. No key bytes are sent to any application server; the entire workflow runs inside the tab you opened. That isolation is meaningful, but it does not extend to extensions, malware, clipboard managers, screenshots, or browser sync — the page can only guarantee what the platform API did with its own buffers.
| Format | Source | Usable for SSH | Envelope header |
|---|---|---|---|
| OpenSSH authorized_keys line | ssh-keygen, PuTTYgen | Yes | Plain Base64 with ssh-rsa prefix |
| OpenSSH private key | ssh-keygen | Yes (native to ssh-agent) | -----BEGIN OPENSSH PRIVATE KEY----- |
| SPKI public PEM | RSA Key Generator | No without re-encoding | -----BEGIN PUBLIC KEY----- |
| PKCS#8 private PEM | RSA Key Generator | No without re-encoding | -----BEGIN PRIVATE KEY----- |
The tool deliberately keeps these formats apart. It does not sign, it does not produce CSRs, and it does not invent an SSH wire envelope because that wire envelope belongs to a different protocol layer.
Generate the Key Pair Step by Step
- Confirm the destination expects RSA-OAEP with SHA-256 and SPKI/PKCS#8 PEM. Read the documentation or source of the consumer library and verify the algorithm name and the accepted key envelopes. If the consumer is OpenSSH itself, stop here and use ssh-keygen instead; this tool will not produce a usable SSH key on its own.
- Choose 2048 or 3072 bits and generate. Use 2048 for broad compatibility and faster browser performance; switch to 3072 if you want a larger security margin and the consumer supports it. The button click is asynchronous, and a job identity prevents an older request from clobbering a newer one, so leave the tab alone until the page shows both PEM blocks.
- Copy the public SPKI PEM to the consumer. The block starts with -----BEGIN PUBLIC KEY----- and is safe to share with any system that needs to encrypt data for the holder. Load it into a configuration file, a database column, or an LDAP attribute, depending on the consumer's expectation.
- Import the PKCS#8 private PEM into protected storage. Because the PEM is not password-encrypted, treat it as already-exposed secret material. Paste it directly into a secret manager, an HSM import flow, or an encrypted keystore. Do not paste it into source control, chat, ticketing systems, analytics, or notes.
- Clear the clipboard and close the tab. Once the private key lives in the secret manager, erase any clipboard residue and close the page so the in-memory buffer is released.
- Run an end-to-end encryption test. Encrypt a known UTF-8 message with the public key on the consumer side, send the ciphertext to a process that holds the private key, and assert exact recovery. A PEM that imports successfully is not enough — OAEP label and mask-generation settings must also match, and the imported algorithm must report the selected modulus length.
If your end goal is SSH access rather than RSA-OAEP encryption, the cleanest move after generation is to convert the SPKI PEM into an OpenSSH public key with a helper utility, or to run ssh-keygen -t rsa -b 3072 on the host that actually needs the key. Either path produces a key the SSH daemon will accept. For a deeper comparison of browser and native paths, see this walkthrough of creating an RSA key without ssh-keygen.
Why RSA-OAEP PEM Keys Are Not Drop-In for SSH
OpenSSH defines its own key encoding so it can carry protocol-specific metadata alongside the RSA parameters, and so it can rotate between rsa-sha2-256, rsa-sha2-512, and the legacy ssh-rsa signature algorithm without breaking older deployments. The PEM envelopes from RSA Key Generator declare an RSA-OAEP key for encryption rather than an RSA signing key, so the OpenSSH wire format cannot read them even though the underlying PKCS#8 body carries the standard n, e, d, p, q and CRT parameters that any RSA private key would.
In practice this means the safest approach when the destination is SSH is to generate the key directly with the SSH tooling chain and reserve the browser tool for RSA-OAEP encryption workflows where the consumer truly speaks PEM. Two workflows that benefit from SPKI/PKCS#8 PEM are protecting a symmetric data key with RSA-OAEP, and exchanging small payloads between systems that already use SPKI/PKCS#8 as their on-the-wire format.
RSA Key Generator still earns a place in an SSH-focused workflow as a learning and verification step. Generating a pair, importing it back into Web Crypto, encrypting a UTF-8 string, and decrypting it round-trips confirms that the private key bytes you handed to your secret manager are valid. That test catches truncation, Base64 padding errors, and accidental header swaps before the key lands in production.
Protect the Private Key Once It Is Generated
A PKCS#8 PEM without a password envelope is plaintext secret material to anyone who reads the file. Anyone holding it can decrypt every ciphertext the matching public key ever encrypts, which is why the private side must travel straight from the generator into the secret manager, with no intermediate copy-paste into chat, support tickets, or source repositories.
Best practice is to treat the import step as one atomic action: open the secret manager, paste, save, close the generator tab, then wipe the clipboard history. Browser extensions, clipboard managers, and screenshot tools remain outside the page's control, so a patched and trusted device matters. For team workflows, generate once per identity and rotate immediately if exposure is suspected.
The generator also fixes the exponent at 65537. That choice avoids exotic exponents that can introduce subtle vulnerabilities, removes a knob that is rarely needed, and keeps every generated pair consistent with the parameter defaults expected by mainstream TLS and RSA-OAEP libraries. If a consumer insists on a non-default exponent, treat that as a red flag and confirm before importing.
If the consumer turns out to be SSH itself, keep RSA Key Generator in your toolkit for non-SSH RSA-OAEP work and use the browser RSA key flow only after you have verified the consumer reads SPKI/PKCS#8 PEM. For SSH access, generate the key with ssh-keygen on the host that needs to log in, copy the resulting public key into authorized_keys, and keep the OpenSSH private key inside ssh-agent or a hardware token.
For a deeper look, see XOR Encryption API Alternative: Browser-Side Repeating Key.