Create Ed25519, ECDSA or RSA key pairs in OpenSSH format — public key, private key, SHA256 fingerprint and randomart.
Save both files into ~/.ssh/, then restrict the private key and add a passphrase:
On the server, append this line to ~/.ssh/authorized_keys (it is the public key, one line):
Optional ~/.ssh/config entry so ssh myserver uses this key:
The same key pair in the PEM containers OpenSSL, JWT libraries and signing tools expect. The PKCS#8 private key is also unencrypted.
you@laptop so you can recognise the key later.~/.ssh/, run chmod 600 on the private key and add a passphrase with ssh-keygen -p.authorized_keys.Ed25519 is the modern default. Its keys are tiny (the public key line is about 80 characters), signing and verification are fast, and the algorithm was designed to be hard to implement wrongly — it doesn't depend on a fresh random number for every signature the way ECDSA does. OpenSSH has supported it since version 6.5 (2014), and so do GitHub, GitLab, Bitbucket and every mainstream cloud. RSA is the fallback for old appliances, network gear or enterprise systems that never learned Ed25519; use at least 3072 bits, which is roughly equivalent to 128-bit security, or 4096 if a policy asks for it. Note that OpenSSH signs with RSA using SHA-2 (rsa-sha2-256/512) — the same ssh-rsa key works, only the ancient SHA-1 signature scheme is disabled. ECDSA on the NIST curves P-256, P-384 and P-521 is mainly for environments whose compliance rules name those curves, such as some FIPS setups. If you're unsure, pick Ed25519.
The key pair is created by your browser's built-in crypto.subtle.generateKey (WebCrypto), the same cryptographic library the browser uses for TLS, seeded from the operating system's secure random source. The page then exports the raw key components and assembles the files by hand: the public key as the familiar one-line ssh-ed25519 AAAA… comment format, and the private key in the openssh-key-v1 container that ssh-keygen has written by default since OpenSSH 7.8, with the cipher set to none. The SHA256 fingerprint is computed over the public key blob exactly the way ssh-keygen -l does, and the randomart picture uses OpenSSH's "drunken bishop" walk, so you can compare both with what your server or GitHub shows. Every algorithm offered here is tested by reading the generated files back with the real ssh-keygen and openssl. Nothing is uploaded, logged or stored: reload the page and the key is gone.
Keys generated here are real, standard OpenSSH keys, but be clear-eyed about the trade-off. The safest place to create a key is the machine that will keep it: running ssh-keygen -t ed25519 locally means the private key is never shown on screen, never touches a clipboard and never passes through a browser with extensions installed. For production servers, deploy keys with wide access or anything you would have to rotate in a hurry, that remains the gold standard. This page is handy when you're on a machine without OpenSSH, need a throwaway key for a test VM or CI job, want a PKCS#8 PEM next to the SSH format, or simply want to see what the formats look like. This version writes unencrypted private keys; if the key will live on a laptop, add a passphrase straight away with ssh-keygen -p -f ~/.ssh/id_ed25519, and load it into ssh-agent so you only type it once per session.
No. The key pair is generated by your browser's WebCrypto API inside this tab and formatted by JavaScript on the page. Nothing is uploaded or stored; closing the tab discards the key unless you saved it.
No. This tool writes unencrypted OpenSSH private keys. To add a passphrase after saving the file, run ssh-keygen -p -f ~/.ssh/id_ed25519 (use your key's path) and enter a new passphrase.
Ed25519 for almost everything: short keys, fast, and supported by OpenSSH 6.5 and later, GitHub, GitLab and most servers. Use RSA 3072 or 4096 only for old systems that don't accept Ed25519, and ECDSA when a policy requires NIST curves.
The keys come from the browser's cryptographic random generator and are standard OpenSSH keys that ssh-keygen reads without complaint. For production servers, running ssh-keygen on the machine that will hold the key is still the gold standard, because the key never passes through a browser at all.
Some non-SSH software, such as code-signing tools, JWT libraries and OpenSSL, expects keys as PKCS#8 (private) and SPKI (public) PEM. It is the same key pair in a different container; OpenSSH itself uses the OpenSSH-format files.