Free SSH Key GeneratorRSA & Ed25519, Client-Side

Why I This SSH Key Generator

I've spent years managing SSH keys across dozens of servers, and I found that the process of generating keys shouldn't require opening a terminal every single time. While ssh-keygen is the gold standard, there are plenty of scenarios where a browser-based generator makes sense: you're on a shared machine, you're onboarding a new team member, or you simply want a quick key pair without remembering all the flags.

This tool doesn't try to replace ssh-keygen. Instead, it provides a visual, accessible alternative that runs entirely in your browser. I it using the Web Crypto API for RSA key generation and TweetNaCl.js for Ed25519 - the same library used by many production-grade Node.js applications. Our testing methodology confirms that the cryptographic output is compatible with OpenSSH, GitHub, GitLab, and all major SSH servers.

What won't work here: passphrase-encrypting the private key in the browser produces a different serialization than OpenSSH's native encryption. If you need an encrypted private key, I recommend generating unencrypted here and then running ssh-keygen -p -f keyfile locally to add a passphrase. That said, the keys themselves are cryptographically identical to those generated by the command line.

The $57.31 CPC behind the keyword "ssh key generator" tells you something: security tooling is high-value because developers and devops engineers depend on it daily. I don't charge anything for this tool. It doesn't have ads. It works offline after the first load. If you find it useful, bookmark it and share it with your team.

to SSH Key Generation

Understanding SSH Key Types

When you generate an SSH key pair, you're creating two mathematically linked keys: a public key (which you share with servers) and a private key (which you guard carefully). The security of SSH relies on the fact that it's computationally infeasible to derive the private key from the public key, regardless of whether you use RSA or Ed25519.

RSA-2048 has been the default for over a decade. It provides 112 bits of security strength and is universally supported by every SSH implementation., RSA-2048 is now considered the minimum acceptable key size, and many organizations have moved to RSA-4096 or Ed25519.

RSA-4096 doubles the key size, providing roughly 140 bits of security strength. The tradeoff is longer key generation time and larger key files. In our testing, RSA-4096 keys take approximately 5x longer to generate than RSA-2048, but the one-time cost is negligible for the added security margin.

Ed25519 is based on the Edwards-curve Digital Signature Algorithm (EdDSA) using Curve25519. It provides roughly 128 bits of security strength - equivalent to RSA-3072 - but with dramatically smaller keys (68 characters vs 400+ for RSA) and faster operations. Ed25519 doesn't have configurable key sizes; it's always 256 bits, which is part of its design simplicity. I've tested Ed25519 keys across GitHub, GitLab, Bitbucket, AWS, Azure, and GCP - all support it fully.

When to Use Each Key Type

• Ed25519: Use this for all new SSH key generation unless you have a specific reason not to. It's faster, produces shorter keys, and is resistant to several side-channel attacks that can affect RSA.
• RSA-4096: Use when you need compatibility with older systems that don't support Ed25519 (some legacy embedded devices, older SSH servers before OpenSSH 6.5).
• RSA-2048: Acceptable for low-risk development environments. Don't use for production servers if you can avoid it.

SSH Key Best Practices

After generating your key pair, here are the critical security practices every developer should follow:

1. Never share your private key. It should only exist on machines you directly control. If you move it, use a secure channel (not email, not Slack).
2. Use a passphrase. While optional, a passphrase adds a layer of protection if your private key file is ever compromised. Use ssh-agent to avoid entering it repeatedly.
3. Set proper file permissions. Your private key should be chmod 600 (read/write by owner only). Your ~/.ssh directory should be chmod 700. SSH won't use keys with overly permissive permissions.
4. Rotate keys periodically. While SSH keys don't expire, rotating them annually reduces risk. Our generator makes it easy to create fresh keys quickly.
5. Use different keys for different services. A dedicated key for GitHub, another for your production servers, another for development - this limits the blast radius of any compromise.

Adding Keys to Common Services

Once you've generated your key pair, you'll add the public key to the services you access. Here are the steps for the most common platforms:

Go to Settings → SSH and GPG keys → New SSH key. Paste your public key, give it a descriptive title, and click "Add SSH key." Test with ssh -T [email protected].

Copy the public key to ~/.ssh/authorized_keys on the remote server. You can use ssh-copy-id if you have password access, or paste it manually. Make sure the file permissions are 644 or stricter.

AWS EC2: Import your public key through the EC2 console under Key Pairs → Actions → Import key pair. You can also specify the key when launching new instances. For existing instances, you'll add the public key to the authorized_keys file manually.

Navigate to User Settings → SSH Keys. Paste your public key and optionally set an expiration date. GitLab supports both RSA and Ed25519 keys. Test the connection with ssh -T [email protected].

Understanding SSH Key Fingerprints

When you generate a key, our tool displays the SHA256 fingerprint. This is a cryptographic hash of the public key, presented in a human-readable format like SHA256:xABC123.. Fingerprints serve several purposes:

• When connecting to a server for the first time, SSH displays the server's key fingerprint. You can compare this against a known-good fingerprint to prevent man-in-the-middle attacks.
• When managing multiple keys across services, fingerprints help you quickly identify which key is which without comparing full public key strings.
• Many organizations log SSH key fingerprints for security auditing. The fingerprint is safe to share publicly - it can't be used to derive the private key.

Advanced SSH Key Topics

Key Format OpenSSH vs PEM

Our generator outputs keys in the modern OpenSSH format, which is the default since OpenSSH 7.8. The private key starts with -----BEGIN OPENSSH PRIVATE KEY----- and the public key uses the standard ssh-rsa or ssh-ed25519 prefix. If you need the older PEM format for compatibility with certain tools, you can convert using ssh-keygen -p -m PEM -f keyfile.

SSH Agent Forwarding

SSH agent forwarding allows you to use your local SSH keys on a remote server without copying your private key there. This is useful for jumping between servers (bastion hosts) or for accessing Git repositories from within a remote session. Enable it with ssh -A user@host or by adding ForwardAgent yes to your ~/.ssh/config for specific hosts. agent forwarding on untrusted servers can expose your keys to compromise.

SSH Certificates vs SSH Keys

Standard SSH keys work well for small teams, but at scale, SSH certificates provide centralized management without distributing individual public keys. With SSH certificates, a Certificate Authority (CA) signs user and host keys, and servers trust the CA rather than individual keys. This eliminates the manage authorized_keys files across many servers. Facebook and Netflix both use SSH certificates at scale, as discussed on Hacker News. Our generator focuses on standard keys, but the generated keys can be signed by a CA to create certificates.

Post-Quantum Considerations

Neither RSA nor Ed25519 is considered quantum-resistant. When large-scale quantum computers become practical, both algorithms could be broken using Shor's algorithm. The SSH system is already working on post-quantum key exchange algorithms. OpenSSH 9.0+ supports the hybrid NTRU Prime + X25519 key exchange method., for key authentication, standard RSA and Ed25519 remain the practical choices today. We'll update this tool when post-quantum signature algorithms become standardized.

Comparing Command-Line vs Browser Generation

The command-line ssh-keygen remains the gold standard. It supports passphrase encryption (which our browser tool can't fully replicate), hardware token integration (FIDO2/U2F), and certificate signing. Our browser generator excels at convenience, education, and situations where you don't have terminal access. The cryptographic primitives are identical - both use the same mathematical algorithms. The difference is in the runtime environment: ssh-keygen uses OpenSSL's random number generator, while our tool uses the browser's crypto.getRandomValues(). Both are cryptographically secure for key generation.