SSH Key Generator

RSA 2048-bit meets current security standards and is NIST-approved through at least 2030. RSA 4096-bit offers a larger security margin for keys that will be in use for many years, but is significantly slower for handshake operations (roughly 4x slower than 2048-bit). For most use cases — server access, GitHub/GitLab, CI/CD pipelines — 2048-bit is sufficient. For keys used in high-security environments or expected to be in use for 10+ years, use 4096-bit. For the best combination of speed and security, use Ed25519 instead.

A passphrase encrypts your private key file so that even if someone obtains the file, they cannot use it without the passphrase. When you use the key, your SSH client asks you for the passphrase to decrypt it (ssh-agent can cache the decrypted key so you are not prompted repeatedly). For user-facing keys (your laptop to your servers), use a passphrase — it provides critical protection if your machine is lost or stolen. For automated CI/CD deployment keys that run without human interaction, passphrase-protected keys are impractical and the key file must be secured by other means (file permissions, secret management systems).

Copy the public key content (starting with "ssh-rsa" or "ssh-ed25519") and append it to the ~/.ssh/authorized_keys file on your server. One public key per line. If the directory does not exist: mkdir -p ~/.ssh && chmod 700 ~/.ssh. Set correct permissions: chmod 600 ~/.ssh/authorized_keys. The fastest method from your local machine: ssh-copy-id user@hostname (using your password for this one-time setup). After that, SSH will use your key automatically. Your private key stays only on your local machine and is never uploaded anywhere.

The comment is a label embedded in the public key after the key data (e.g. ssh-ed25519 AAAA... user@laptop). It has no effect on authentication — it is purely descriptive. Use it to identify the key's origin when you check authorized_keys on a server: who created this key, from which machine, and for what purpose. Common formats: user@hostname (default), your email address, or a descriptive label like "ci-deploy-prod-2026". When you have multiple keys in authorized_keys, a meaningful comment is how you know which key to revoke if something goes wrong.

The fingerprint is a SHA-256 hash of the public key, displayed in Base64 format (e.g. SHA256:abc123...). It is a compact way to identify and verify a specific key. When you first connect to a server with SSH, the server shows you its host key fingerprint — you verify it to confirm you are connecting to the right server. When you upload a public key to GitHub, GitLab, or other services, they show you the fingerprint. If the fingerprint matches what this tool shows, the key was uploaded correctly. You can also run ssh-keygen -l -f ~/.ssh/id_ed25519 on your machine to verify fingerprints locally.

Yes. All key generation uses the Web Crypto API, which is a native browser API providing cryptographically secure operations backed by the operating system's entropy source. The random number generation uses crypto.getRandomValues(), not the insecure Math.random(). The generated keys are equivalent in security to those produced by ssh-keygen on the command line. Nothing is sent to any server — the key pair exists only in your browser session.

Never replace your existing authorized_keys — append your new public key as an additional entry. Then open a second SSH session (without closing the current one) to test the new key. Only after confirming the new key works should you remove old keys or change your password policy. If you lock yourself out, you will need console access to the server (cloud providers call this "emergency console" or "rescue mode") to manually edit authorized_keys.