SSH Key Generator - Ed25519, RSA, ECDSA

SSH Key Generator: Create an Ed25519, RSA or ECDSA Key Pair

This SSH key generator creates a complete key pair in your browser — private key, public key, fingerprints and randomart — without installing OpenSSH, opening a terminal or sending anything to a server. Choose an algorithm, add a comment and an optional passphrase, and you get the authorized_keys line to paste on the server and a private key file to download and keep. Every byte of key material is produced locally by the browser’s cryptographic random number generator; nothing is transmitted, logged or stored.

It is the fastest route to a key when you are on a locked–down workstation, a Windows machine without OpenSSH installed, a Chromebook, or a borrowed laptop — and it is a genuinely useful way to see what ssh-keygen actually produces, since the OpenSSH private key container, the PEM encoding and the PuTTY .ppk container are all shown side by side for the same key.

Supported Key Types

Ed25519 is generated with the browser’s native Web Crypto implementation, which requires Chrome 113 or later, Safari 17 or later, or Firefox 117 or later. On an older browser the tool will tell you Ed25519 is unavailable rather than silently falling back — pick RSA or ECDSA in that case, or update the browser.

Which Algorithm Should You Choose?

For anything new, choose Ed25519. It gives roughly the security of a 3072–bit RSA key in a public key short enough to fit on one line, signs and verifies faster, and has no parameter choices to get wrong. It has been supported by OpenSSH since version 6.5 (2014), and by GitHub, GitLab and every current Linux distribution, so compatibility is rarely a real constraint any more.

Reach for RSA when something on the other end refuses Ed25519: older network appliances, some hardware load balancers, legacy Java SSH libraries, and a shrinking number of hosting control panels. Use 3072 or 4096 bits — 2048 remains acceptable in most policy frameworks but has no headroom left. Note that generating a 4096–bit RSA key in a browser genuinely takes time; several seconds is normal and the tab may feel unresponsive while the prime search runs.

ECDSA is mainly useful when a compliance regime names the NIST curves explicitly. It is smaller and faster than RSA, but it has no advantage over Ed25519 for general use, and it is more sensitive to the quality of randomness during signing.

How to Generate an SSH Key Here

1. Select a key type from the cards. Ed25519 is preselected.
2. Set the comment. This is the trailing label on the public key line — conventionally an email address or user@hostname. It has no cryptographic role, but it is what lets you identify a key later in a server’s authorized_keys file, so make it descriptive.
3. Add a passphrase (optional but recommended). The private key is then encrypted with AES–256 and a PBKDF2–derived key, so the file is useless to anyone who copies it without the passphrase.
4. Generate. The key pair, both fingerprints and the randomart image appear immediately.
5. Save the private key. Download it — it is named id_ed25519, id_rsa or the ECDSA equivalent to match OpenSSH convention — and put it in ~/.ssh/. This is the only chance to keep it; nothing is stored here.
6. Install the public key. Copy the single–line public key and append it to ~/.ssh/authorized_keys on the server, or paste it into the SSH keys page of GitHub, GitLab or your cloud provider.

Setting permissions after download

OpenSSH refuses to use a private key that other users can read. After moving the downloaded file into place:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

On the server side, ~/.ssh/authorized_keys must also be 600. “Permissions 0644 for ‘id_ed25519’ are too open” is the single most common error after generating a key by any method.

Output Formats Explained

• OpenSSH — the -----BEGIN OPENSSH PRIVATE KEY----- container that modern ssh-keygen writes. This is what you want for Linux, macOS, WSL and the Windows OpenSSH client.
• PEM (PKCS#8) — -----BEGIN PRIVATE KEY-----, or -----BEGIN ENCRYPTED PRIVATE KEY----- when a passphrase is set. This is the format most libraries and automation tooling expect, and OpenSSH 7.8 and later reads it directly.
• PuTTY .ppk — a PuTTY private key version 3 container for PuTTY, Pageant, WinSCP and FileZilla on Windows.

One honest limitation: the .ppk export is written unencrypted, because PuTTY’s encrypted v3 container uses Argon2 key derivation that this tool does not implement. If you need a passphrase–protected key for PuTTY, export the PEM form here, load it into PuTTYgen, and set the passphrase there — or use the OpenSSH or PEM output, both of which are genuinely encrypted when you supply a passphrase.

Fingerprints and Randomart

Two fingerprints are shown for every key. The SHA–256 fingerprint is what current OpenSSH displays — a Base64 digest prefixed with SHA256: — and it is the value to compare when a host or a service asks you to confirm a key. The MD5 fingerprint, the colon–separated hex form, appears because some older systems and cloud consoles still display keys that way; it is fine for identification and should not be treated as a security guarantee.

The randomart is the ASCII–art square OpenSSH draws from the fingerprint. It exists because humans compare pictures more reliably than they compare 43–character Base64 strings: if the shape looks different from the one you remember, something changed. It carries no information the fingerprint does not.

The equivalent terminal commands

If you do have a terminal, these produce the same kinds of key:

ssh-keygen -t ed25519 -C "you@example.com"
ssh-keygen -t rsa -b 4096 -C "you@example.com"
ssh-keygen -t ecdsa -b 384 -C "you@example.com"

To inspect a key you already have: ssh-keygen -lf ~/.ssh/id_ed25519.pub prints the SHA–256 fingerprint, and adding -v prints the randomart too. Copying a public key to a server is easiest with ssh-copy-id user@host.

Is Generating an SSH Key in a Browser Safe?

The cryptography itself is sound. Keys come from crypto.getRandomValues() and the Web Crypto API — the same cryptographically secure random source the browser uses for TLS — not from Math.random(), and the page runs entirely client–side with no network call carrying key material.

The honest caveat is about threat model rather than mathematics. A browser tab is a busier environment than a shell: extensions can read page content, and you are trusting that the page you loaded is the page that was published. For a key that guards production infrastructure, a bastion host or a signing identity, generate it with ssh-keygen on the machine that will use it — that is the recommendation regardless of which online generator you use. For lab work, a personal VPS, a throwaway cloud instance, a CI deploy key you can rotate freely, or learning what the formats look like, generating here is entirely reasonable.

Whatever you generate, apply the usual hygiene: one key per person and per purpose rather than one shared key, a passphrase on anything that lives on a laptop, and rotation when someone leaves or a device goes missing. If you also need to check a certificate presented by a server, the X.509 certificate decoder parses it in the same client–side way, and the hash generator is handy for verifying a downloaded key file against a published checksum.

Frequently Asked Questions

Are the generated keys sent to a server?

No. Key generation, passphrase encryption and fingerprinting all run in your browser. There is no upload, no logging and no storage — close the tab and the key is gone, which is why you must download the private key before leaving the page.

Ed25519 or RSA — which should I pick?

Ed25519 for anything new. It is smaller, faster and simpler, with security comparable to a 3072–bit RSA key, and it has been supported by OpenSSH since 6.5. Choose RSA 3072 or 4096 only when a legacy device or library rejects Ed25519.

What do I do with the public key?

Append the single–line public key to ~/.ssh/authorized_keys on the server you want to reach, or paste it into the SSH key settings of GitHub, GitLab, or your hosting provider. That file must be mode 600 and owned by the user logging in.

Does the passphrase actually encrypt the key?

Yes, for the OpenSSH and PEM outputs: the private key is encrypted with AES–256 using a PBKDF2–derived key, in the encrypted PKCS#8 form that OpenSSH 7.8 and later loads directly. The PuTTY .ppk export is the exception and is written unencrypted.

Can I get the private key in PuTTY format?

Yes — switch the output format to .ppk for a PuTTY v3 container that works with PuTTY, Pageant and WinSCP. To add a passphrase to it, load the PEM export into PuTTYgen and set one there.

Why is my RSA key taking so long to generate?

RSA key generation searches for large random primes, and the cost grows sharply with size. A 4096–bit key can take several seconds in a browser and may make the tab feel frozen. Ed25519 and ECDSA are effectively instant because they need no prime search.

SSH says my key permissions are too open. How do I fix it?

Run chmod 600 on the private key and chmod 700 on ~/.ssh. OpenSSH refuses to use a private key readable by other users, and this is the usual first error after downloading a key file.

Can I recover a key I generated earlier here?

No. Nothing is stored, so a key exists only in the page until you download it. If you lost it, generate a new pair and replace the public key on the server — and remove the old entry from authorized_keys while you are there.