SSH Key Generator

Generating SSH Keys: The Right Way

SSH keys are the cornerstone of secure server access, they replace passwords with cryptographic proof of identity. The mechanics are well-understood (asymmetric key cryptography, 1970s math, decades of deployment), but the operational details, which algorithm, what size, where the files go, how to protect them, matter more than ever as keys live longer (often 5-10 years) and get used to access more services (servers, GitHub, AWS, Kubernetes clusters, CI runners). This tool generates RSA and ECDSA keys in the browser; this guide covers the practical context.

How SSH Keys Work

An SSH key pair has two halves:

• Private key, stays on your laptop. Mathematical secret. Used to PROVE you're you.
• Public key, shared with servers. Used to VERIFY proofs from a private key holder.

When you connect, the server sends a challenge; your SSH client signs it with the private key; the server checks the signature against the public key it has on file. Successful signature = you have the matching private key = you're authenticated.

The math relies on one-way functions: easy to derive public from private, infeasible to derive private from public.

Algorithm Choices

Ed25519 (preferred)

• Key size: 256-bit (small, both files fit in 1-2 lines).
• Security: ≈ RSA 3072 / ECDSA P-256.
• Speed: very fast generation, very fast signing/verifying.
• Safety: deterministic signatures, no RNG-bug class of attacks.
• Compatibility: OpenSSH 6.5+ (released 2014). All modern systems.

The default for new keys since ~2015 among security-conscious users.

This tool doesn't generate Ed25519 (Web Crypto API doesn't include it natively, would need a JS implementation, which adds attack surface). Use the CLI for Ed25519.

RSA

• Key size: 2048-bit (minimum acceptable), 4096-bit (recommended for long-lived keys).
• Security: 2048-bit ≈ 112-bit symmetric; 4096-bit ≈ 128-bit symmetric.
• Speed: slower than ECDSA/Ed25519, especially for 4096-bit. Negligible in practice.
• Compatibility: universal, works with every SSH server ever shipped.

The "everywhere compatible" choice. If you're targeting legacy systems or unsure about the server's SSH version, RSA 4096 is the safe bet.

ECDSA

• Curves: P-256, P-384, P-521 (Web Crypto supports the first two).
• Security: P-256 ≈ RSA 3072; P-384 ≈ RSA 7680.
• Speed: faster than RSA, slower than Ed25519.
• Caveat: requires a high-quality RNG at SIGN time (not just generation). Bad RNG = private key leakage (this has happened in the wild: PS3 firmware, Bitcoin wallets, etc.).
• NIST curves: some users avoid them on principle (suspicion of NSA influence on curve parameters).

If you've decided against RSA but Ed25519 isn't available, ECDSA is fine, modern systems have good RNGs.

DSA (do not use)

Deprecated. Disabled by default in OpenSSH 7+. Insecure with current key sizes. If you find a DSA key in your ~/.ssh, generate a replacement.

Output Formats

Private key (PEM)

PEM = "Privacy-Enhanced Mail." Base64 of the binary DER-encoded key, with header/footer. Universal format read by OpenSSH, Putty (with conversion), openssl, libraries, etc.

OpenSSH 7.8+ has its own private key format (-----BEGIN OPENSSH PRIVATE KEY-----) which is the default for new ssh-keygen runs. PEM remains compatible everywhere; convert with ssh-keygen -p -m PEM -f keyfile if needed.

Public key (OpenSSH single-line)

Three parts: algorithm + base64-encoded key data + comment. Paste into authorized_keys files or service web UIs.

Setup Walkthrough

1. Generate

Use this tool, or:

Will prompt for a passphrase (recommended, see below).

2. Set permissions

SSH is paranoid about file permissions:

600 on private = user-only read/write. SSH refuses to use a private key with broader permissions.

3. Install public key on server

Or manually:

For GitHub/GitLab/Bitbucket: paste the public key into Settings → SSH keys.

4. Test

For GitHub: ssh -T git@github.com (should say "Hi !").

5. Configure ssh-agent

You type the passphrase once; subsequent connections use the agent.

6. SSH config

In ~/.ssh/config:

Then ssh myserver connects with the right settings.

Passphrases and ssh-agent

A passphrase encrypts the private key file. Without it, anyone reading the file has your identity. With it, they need the passphrase too.

The agent (ssh-agent) holds decrypted keys in memory for the session. Type the passphrase once; use the key many times.

• macOS: Built-in agent integrates with Keychain. Add to ~/.ssh/config:
• Linux: Most desktops start an agent automatically. ssh-add adds keys.
• Windows / WSL: OpenSSH agent service; enable in Services or use ssh-agent in WSL.

For agent forwarding (ssh -A), be careful: it exposes your keys to the remote machine's root. Use -o ForwardAgent=no by default; forward only when needed.

Multiple Keys, Multiple Hosts

Don't use one key for everything. Best practice:

• Personal laptop → personal services: one key.
• Personal laptop → work resources: separate key (work can revoke without affecting personal).
• Work laptop → work resources: another separate key.
• CI/CD runner: dedicated key, restricted on server side.
• Backup access key: different key, kept offline, used only for emergency.

Per-host keys make rotation simpler, losing one doesn't compromise everything.

Manage with ~/.ssh/config:

Clone with git clone git@github.com-work:org/repo.git to use the work key.

Restricting Keys on the Server

In authorized_keys, prefix a public key with restrictions:

Options:

• command="...", force a specific command; key can only run that program.
• no-port-forwarding, no SSH tunneling.
• no-pty, no interactive shell.
• from="198.51.100.0/24", restrict source IPs.
• expiry-time="...", auto-expire (OpenSSH 8.2+).

Use for CI/CD keys, backup keys, deploy keys, anything not needing full shell access.

Rotation

Plan to rotate keys every 1-2 years. Procedure:

1. Generate new key.
2. Add new public key to all servers (in addition to old).
3. Test connectivity with new key.
4. Switch client config to use new key.
5. Remove old public key from servers.
6. Securely delete old private key.

If a key is compromised: remove its public key from authorized_keys everywhere FIRST, then deal with the leaked private key.

Detecting and Inspecting Keys

Get the fingerprint

GitHub shows the same fingerprint in your SSH key list. Compare to confirm match.

Get the public key from private key

Useful when .pub is missing.

Connect and see which key is used

Common Mistakes

Sharing the private key. Never. If a service or person needs to authenticate, they generate their own key and share the public half.

Reusing the same key everywhere. Compromise of one machine compromises everything.

No passphrase. Means a laptop theft is a full compromise.

Generating in browser-based tools that aren't local. Many "online ssh key generator" sites generate server-side or log the keys. Verify network activity before trusting any browser tool, including this one (use DevTools).

Adding the public key to the wrong file. Use authorized_keys on the server, not known_hosts (different file, different purpose).

Forgetting agent forwarding security. Agent forwarding to a compromised server gives the attacker your keys for the session.

Privacy

Key generation uses the browser's Web Crypto API (crypto.subtle.generateKey), a native, JS-isolated cryptographic implementation. The private key is exported to PEM and the public key to OpenSSH single-line format entirely in JavaScript running in your tab. Open DevTools Network during use: zero outbound requests. Verify this yourself before trusting; the cardinal rule of crypto tooling is "if it touches the network, the key is suspect."