🔑 SSH Key Generator

What this tool does

SSH Key Generator creates an SSH key pair — a public key you can upload to a server's ~/.ssh/authorized_keys file and a corresponding private key you keep locally — in your browser. Key material is generated by Web Crypto's crypto.subtle.generateKey, then re-serialised into either the OpenSSH wire format described by RFC 4253 §6.6 and OpenSSH's PROTOCOL.key, or the PuTTY .ppk v3 format used by PuTTY 0.75+ and WinSCP.

You can also drag an existing key file into the page (OpenSSH PEM or PuTTY v3) to inspect its fingerprints or re-export it in a different format with a different passphrase. The imported key never leaves the page either — parsing, decryption, re-encryption, and fingerprinting all run in your browser tab.

Output formats

• OpenSSH — PEM block starting with -----BEGIN OPENSSH PRIVATE KEY-----, described in OpenSSH's PROTOCOL.key. When a passphrase is set, the private section is encrypted with aes256-ctr keyed via bcrypt-pbkdf, matching what ssh-keygen -p produces. Save as ~/.ssh/id_ed25519 (or id_rsa / id_ecdsa) and chmod 600.
• PuTTY .ppk v3 — text format used by PuTTY 0.75+ (2021), WinSCP, FileZilla, and Pageant on Windows. When a passphrase is set the private section is encrypted with AES-256-CBC keyed via Argon2id; the file carries an HMAC-SHA-256 tag over the algorithm, encryption type, comment, public blob, and private blob. v1 and v2 .ppk files are not emitted (v2 used SHA-1 derivation; v3 is the modern replacement).

The public key is always emitted as the single-line authorized_keys format defined by RFC 4253 §6.6: an algorithm string (e.g. ssh-ed25519), one base64-encoded wire blob, and an optional trailing comment.

How to use the generated key

1. For OpenSSH: save the private key as ~/.ssh/id_ed25519 (or id_rsa / id_ecdsa) and chmod 600 it. SSH refuses to use a private key that is world-readable.
2. For PuTTY: save as mykey.ppk and load it via Pageant or the connection profile's "Auth" → "Private key file" field. PuTTY 0.75+ is required to read the v3 format emitted here.
3. Append the public key (single line) to ~/.ssh/authorized_keys on the server you want to log in to. Replace user@hostname with something useful so the key is easy to identify later.
4. Test the login with ssh -i ~/.ssh/id_ed25519 user@server before closing your existing session, so a mistake can't lock you out.
5. Verify the server's fingerprint on first connect against the SHA256 value the server admin advertises out-of-band.

Adding the key to ~/.ssh/authorized_keys

sshd reads one public key per line from ~/.ssh/authorized_keys in the home directory of the account you log in as. If the directory or file is missing, create them; if their permissions are too open, OpenSSH's StrictModes check (on by default) silently ignores the file and falls back to password auth.

mkdir -p ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
cat id_ed25519.pub >> ~/.ssh/authorized_keys

The panel next to the generated key gives the same commands with your key filled in, plus an ssh-copy-id one-liner. From Windows PowerShell, where ssh-copy-id isn't available:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

• Permissions: ~/.ssh must be 700 (drwx------), authorized_keys 600 (-rw-------), and the home directory itself must not be group- or world-writable.
• Ownership: both must belong to the login user. If you created them as root for someone else, run chown -R user:user ~user/.ssh.
• One key per line: use >> (append), never >, which overwrites every existing key. A key pasted without a trailing newline gets glued to the next one and both stop working.
• SELinux (RHEL, Fedora, Rocky): if the key is still refused, restore the file labels with restorecon -Rv ~/.ssh.
• Debugging: ssh -v user@server shows which keys the client offered; the server's journalctl -u ssh (or sshd) or /var/log/auth.log says why one was rejected, e.g. bad ownership or modes.