Secure Shell (SSH) Public Key Extractor

Introduction:

An SSH public key is the shareable half of a key pair. It is the line you place in authorized_keys, compare during access reviews, or match against a fingerprint shown by ssh-keygen and server prompts. When the public half is missing, the practical job is to recover exactly the same public bytes from the material you still have and turn them into a clean server-ready entry.

This page accepts three broad starting points: an OpenSSH private key block, an RSA private key PEM block, or an existing public key line. It then extracts one supported key, reports Key type, Bits, SHA-256 fingerprint, MD5 fingerprint, and Derivation path, and builds an authorized_keys line you can copy, download, or export for review.

That makes it useful for routine access setup, migration work, and audits. You can confirm that a private key still corresponds to the public identity you expect, normalize a pasted public key line before handing it to another administrator, or keep a quick record with the fact-sheet, trace, CSV, DOCX, and JSON exports.

A matching fingerprint is only an identity check. It shows that two public-key blobs are the same. It does not prove that the private key is trusted, that file permissions on the server are correct, or that an account will accept the resulting entry once you paste it into place.

Technical Details:

SSH public keys are structured records, not just long random-looking strings. The public half is encoded as an algorithm identifier plus binary key data. In a public key line, that record is Base64-encoded and usually followed by an optional comment. In an authorized_keys file, any restriction options come before the key and the trailing comment is not used for authentication.

The extraction path on this page always tries to reduce the input to the same thing: the public key blob that SSH software actually fingerprints and compares. That is why SHA-256 fingerprint and MD5 fingerprint stay the same even if you change the optional comment or prepend restrictions such as command= or no-port-forwarding. Those additions alter the full authorized_keys line, but they do not alter the public key bytes themselves.

Three parser paths are exposed through Derivation path. openssh_private_key means the page found a supported key in an OpenSSH private-key container. rsa_private_pem means it derived the public half from an RSA private key PEM block. public_key_line means it decoded a supported public key line directly. If more than one supported key is present, only the first one is turned into output and the rest are counted in Keys ignored.

Bit length depends on the key family. Ed25519 always reports 256 bits. The supported ECDSA families are the NIST P-256, P-384, and P-521 curves. RSA size comes from the modulus, which is stored as an SSH mpint. Positive mpint values may need a leading zero byte in the encoded blob, so a blob can be one byte longer than the true RSA key size without meaning the key gained extra security bits.

The fingerprint formulas below summarize what the page is actually hashing.

Everyday Use & Decision Guide:

Start with the least sensitive material that answers your question. If you already have a public key line, use that first. It gives you the same Key type, Bits, and fingerprints without exposing private key material. Reach for a private key only when you truly need to recover the public half or prove that a private file still corresponds to a known fingerprint.

The most important habit is to compare the extracted SHA-256 fingerprint with a trusted source before you install the generated entry anywhere. A matching fingerprint is the best sign that the derived public key is the one you meant to use. If the fingerprint does not match, the safest assumption is that you pasted the wrong key, trimmed the input, or mixed several keys into the same block.

• Check Derivation path before you copy anything. It tells you whether the page really parsed a private key or simply found a public key line somewhere in the pasted text.
• Re-enter comments you want to keep. When you paste a public key line, the generated authorized_keys line uses the optional Comment field on the page, not the trailing comment from the source line.
• Treat restrictions as policy, not identity. The authorized_keys options prefix is prepended verbatim and changes the final line, but it does not change the key fingerprints.
• Split multi-key blocks into separate runs. A nonzero Keys ignored count means the page did not build output for every supported key it found.
• Use the trace when the result looks odd. Derivation Trace is the fastest way to see whether parsing failed early, fell back from PEM parsing, or succeeded through a different path than you expected.

The export buttons are best used after you have already decided the result is correct. Key Fact Sheet is useful for reviews, Authorized Entry is useful for handoff, Derivation Trace helps with troubleshooting, and the JSON export keeps the same facts in a machine-readable form.

Step-by-Step Guide:

1. Paste into Key input, upload a file, or drop a file onto the text area. If you already have a public key line, prefer that over a private key block.
2. Open Advanced only when you need an authorized_keys options prefix or a new trailing Comment. If you want to keep a source comment from a pasted public key line, type it again here.
3. Click Extract Key. A successful run shows the summary block with algorithm, bit length, and fingerprints. A failed run surfaces a warning such as unsupported PEM, encrypted PKCS#8, malformed OpenSSH data, or no detectable key.
4. Read Key Fact Sheet first. Confirm Key type, Bits, SHA-256 fingerprint, Derivation path, Keys detected, and Keys ignored.
5. Switch to Authorized Entry and inspect the full authorized_keys line. Make sure the options prefix and comment say exactly what you intend before you copy or download the result.
6. Use Derivation Trace and JSON when you need evidence of how the result was built, then use the CSV or DOCX exports only after the output fields already look correct.

Interpreting Results:

SHA-256 fingerprint is the field that matters most for identity checks. That is the modern default fingerprint style in current OpenSSH tooling. MD5 fingerprint is still helpful for older systems and screenshots, but if you only compare one value, compare SHA-256.

Derivation path explains how the public key was obtained, not whether the key is good or safe. A value of rsa_private_pem or openssh_private_key means the page derived the public half from a private key. A value of public_key_line means it decoded a public key line directly. If the path surprises you, the pasted text probably contained extra material or an unsupported private-key form.

• Keys detected and Keys ignored are workflow signals. They tell you whether the input held more than one supported key, not whether the first key is valid for login.
• Bits is descriptive, not a policy verdict. It reports the parsed key size, but it does not tell you whether that size meets your organization's current SSH policy.
• Line SHA-256 prefix is not the same thing as SHA-256 fingerprint. The line prefix hashes the whole generated text line, so it changes when you edit restrictions or comments.
• A successful extraction still leaves deployment checks to you. Server-side ownership, file permissions, account names, certificates, and host policy all sit outside what this page can confirm.

If the result looks structurally correct but login still fails, trust the fingerprint comparison first and then move outward. Check which account should receive the key, whether the destination file is really authorized_keys, whether the added options are too restrictive, and whether the server allows that key type for the target account.

Worked Examples:

Checking a public Ed25519 line before granting access

A public key line such as ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHCW7VMlhFl6J/IyZyxPQqDNcyhPjSVC3cdz2lVB6K+y sample@example should produce Key type ssh-ed25519, Bits 256, Derivation path public_key_line, Keys detected 1, and Keys ignored 0. The matching SHA-256 fingerprint for this sample is MemU2vPeZKVZ8p9dG520BM8wPA/3qr5mfwSVDwS63ZU.

Leave the page's Comment field blank and the generated authorized_keys line will not carry over sample@example. If you want a trailing comment in the rebuilt line, enter it explicitly before you extract.

Deriving an RSA public entry from a private key PEM

Paste a 2048-bit RSA private key PEM block, set authorized_keys options to from="10.0.0.0/8",no-port-forwarding, and set Comment to ops@lab. The result should show Derivation path rsa_private_pem, Key type ssh-rsa, and Bits 2048. For the disposable sample generated during review, the SHA-256 fingerprint is 4fnbAcbmLNQAbp7Lb8nC/5m+h35SGD4dPDGwxh2Ydfs.

The generated authorized_keys line begins with the restriction string and ends with ops@lab, but the fingerprints do not change. That is the expected result because restrictions and comments sit outside the public key blob being fingerprinted.

Troubleshooting a pasted block that contains more than one key

Suppose you paste two supported public key lines into the same text area because you copied the whole contents of an old authorized_keys file. The page still produces only one result set. In Key Fact Sheet, Keys detected rises to 2 and Keys ignored rises to 1. The authorized_keys line in the output belongs only to the first recognized key.

That is a signal to split the input and run each key separately. If the warning instead says the PEM input is unsupported or encrypted, the corrective path is different: export a public key line elsewhere or convert the private key into a supported OpenSSH or RSA PEM form before you try again.

FAQ:

Responsible Use Note:

Use a public key line whenever that is enough. Only paste private key material when you genuinely need to recover or verify the public half, and avoid using live production secrets when a disposable sample or an offline command would answer the same question.

This warning matters more here than on many other utility pages because the form state is mirrored into the URL. Even though the key processing happens in the browser, sensitive input can still show up in history, copied links, chat screenshots, browser sync, and web-server logs if the page URL is shared or captured after you paste the key.

Glossary:

authorized_keys

The server-side file format that stores public keys and optional restrictions for SSH login.

Public key blob

The decoded binary key data that SSH fingerprints and compares during key-based authentication.

Fingerprint

A digest summary of the public key blob used to match one public key against another.

Derivation path

The parser route that produced the current result, such as a private-key path or a direct public-key-line path.

mpint

The SSH multi-precision integer encoding used for values such as the RSA modulus.

References:

• RFC 4251: The Secure Shell (SSH) Protocol Architecture, RFC Editor.
• RFC 4253: The Secure Shell (SSH) Transport Layer Protocol, RFC Editor.
• RFC 5656: Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC Editor.
• RFC 8709: Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol, RFC Editor.
• ssh-keygen(1) manual page, OpenBSD Project.
• sshd(8) manual page, OpenBSD Project.
• Information Exposure Through Query Strings in URL, OWASP Foundation.