Nexinon

SSH Key Generator

Generates SSH keys (Ed25519 or RSA) ready for GitHub, GitLab and authorized_keys.

Algorithm

Modern recommended default — short key, instant generation.

A label to identify the key (by convention, an email) — appended to the public key line.

What an SSH key is

SSH (Secure Shell) is the protocol used to access remote servers and authenticate to Git services (GitHub, GitLab, Bitbucket) without typing a password. An SSH key is an asymmetric cryptography pair: the public key is installed on the server (or registered with the service), and the private key stays on your machine alone — on every connection, the SSH client mathematically proves possession of the private key without ever sending it. It's safer than a password (nothing reusable travels, nothing leaks server-side) and is the standard authentication method for Git, deploys and CI.

Ed25519 or RSA — which to choose

Ed25519 is the modern standard and OpenSSH's own current recommendation: a very short key (the whole public key fits in ~80 characters), instant generation, fast signing and no size parameter to get wrong. Use RSA only when you need to talk to a legacy system that doesn't accept Ed25519 — OpenSSH has supported Ed25519 since 2014, so the exception keeps getting rarer. If you choose RSA, 4096 bits is this tool's default (same stance as the RSA Key Pair Generator); 3072 and 2048 remain available for faster generation on limited devices.

The two formats generated

The public key comes out as a single line — "ssh-ed25519 AAAA... comment" — exactly the format a server's authorized_keys file and the key fields on GitHub/GitLab expect. The private key comes out in the OpenSSH envelope ("-----BEGIN OPENSSH PRIVATE KEY-----"), the native format of modern ssh-keygen — it is not the generic PEM (PKCS8) of other tools, and the two envelopes are not interchangeable. The fingerprint (SHA256:...) is the public key's digital fingerprint: the same value "ssh-keygen -l" computes and GitHub shows in your list of registered keys.

How to use the generated key

On your computer, save the private key under ~/.ssh/ (e.g. ~/.ssh/id_ed25519) and, on Linux/macOS, restrict its permissions with "chmod 600" — SSH refuses a private key readable by other users. On GitHub, paste the public key line under Settings → SSH and GPG keys; on GitLab, under Preferences → SSH Keys. On your own server, append the same line to the target user's ~/.ssh/authorized_keys file. The private key is never sent anywhere — it stays on your machine, and the SSH client uses it locally to answer the server's challenge.

Difference from the RSA Key Pair Generator

The catalog has two key pair tools, and they are not interchangeable. The RSA Key Pair Generator produces generic PEM (SPKI/PKCS8) — the format of certificates, of JWTs signed with RS256/PS256 and of integrations expecting a plain "RSA key". This tool produces keys in SSH's own formats: a single line for the public key, the OpenSSH envelope for the private one. If you need to sign a JWT or feed OpenSSL, use the RSA Key Pair Generator; if you need to access a server or a Git service over SSH, use this one.

Frequently asked questions

No. Generation happens entirely in your browser, using the native Web Crypto API (crypto.subtle) — this tool makes no network calls.

It's the algorithm OpenSSH itself recommends: security comparable to RSA at 3072+ bits with a much smaller key, instant generation (no probabilistic search for large primes) and an implementation more resistant to subtle mistakes. RSA remains available here for compatibility with legacy systems.

Generation relies on the browser's native support (Web Crypto API), which arrived in Safari 17, Firefox 129 and Chrome/Edge 137. On an older browser, the tool hides the option and explains why — RSA keeps working normally. Updating the browser fixes it.

Not in this version — OpenSSH's encrypted format uses a key derivation function (bcrypt_pbkdf) that doesn't exist in the browser's Web Crypto API. To add a passphrase, save the key and run "ssh-keygen -p -f <file>" in your terminal: the same file is re-encrypted in place, without generating a new key.

Copy the public key (the entire single line), open Settings → SSH and GPG keys → New SSH key on GitHub, paste it into the Key field and save. Then save the private key under ~/.ssh/ on your machine and test the connection with "ssh -T git@github.com".

The SHA-256 hash of the public key, in Base64 — a short "digital fingerprint" that identifies the key without exposing any of it. It's the same value "ssh-keygen -l" computes and GitHub/GitLab display in your list of registered keys: if the fingerprint matches, it's the same key.

It's just a label, with no cryptographic effect: it goes at the end of the public key line (and inside the private file) to identify whose or which machine's key it is — by convention, an email or user@machine. It can be left empty.

Not directly — the OpenSSH envelope is not the PEM PKCS8 that JWT/OpenSSL tools expect (see "Difference from the RSA Key Pair Generator", above). For JWT (RS256/PS256), generate with the RSA Key Pair Generator. Converting between the two formats is possible outside the browser (e.g. "ssh-keygen -p -m PEM"), but is out of this tool's scope.

Nexinon Principles

Privacy

Your data never leaves your browser.

No account needed

Use it now, no account or password.

Free

No usage limits, no paid plan.

Trustworthy content

Full explanation behind every tool, not just the result.
See the live proof — Trust Center

Other Security tools

View all