Secure Shell (SSH) Public Key Extractor
Extract an SSH public key from private-key text or public lines, then check fingerprints, bit length, derivation path, and authorized_keys output.SSH Public Key Extractor
| Field | Value | Copy |
|---|---|---|
| {{ row.field }} | {{ row.value }} |
| Component | Value | Copy |
|---|---|---|
| {{ row.field }} | {{ row.value }}{{ row.value }} |
| # | Stage | Status | Detail | Evidence | Copy |
|---|---|---|---|---|---|
| {{ row.idx }} | {{ row.stage }} | {{ row.status }} | {{ row.detail }} | {{ row.evidence }} |
An SSH public key is the part of a key pair that a server can store safely for authentication. The private key stays with the user or automation system; the public key goes into an authorized keys file, a deployment record, or an access review. When only private-key material is available, the practical job is to recover the public key bytes without changing the identity that SSH will later compare.
Public-key lines also carry surrounding text that can confuse reviews. Options may restrict how a key can be used, and comments help humans identify the owner, but the fingerprint is calculated from the public key blob itself. That means a comment edit can change the visible line without changing the key identity.
The extractor accepts three common starting points: an OpenSSH private key, an RSA private key PEM, or an existing public key line. It reports the key type, bit length, SHA-256 fingerprint, MD5 fingerprint, derivation path, detected-key counts, and a rebuilt server-ready line. The optional restrictions and comment controls are useful for access setup, but they should be treated as policy text around the public key, not as part of the key identity.
A matching fingerprint proves only that two public key blobs match. It does not prove that the private key is stored safely, that server file permissions are correct, that the account accepts the key type, or that added restrictions are suitable for the intended login.
How to Use This Tool:
Use the least sensitive input that answers the question. A public key line is enough for most fingerprint and authorized-entry checks.
- Paste text into
SSH key input, drag a supported key file onto the field, or chooseBrowse SSH key file. The first supported key is used when several are present. - Use
authorized_keys optionsonly when you need a restrictions prefix such as a forced command or disabled forwarding. Leave it blank for a plain key line. - Use
Comment overridewhen the trailing note should be changed or when a private key source has no comment. Blank keeps a detected public-line comment when one is available. - Read
Key Fact Sheetfirst. ConfirmKey type,Bits,SHA-256 fingerprint,Derivation path,Keys detected, andKeys ignored. - Open
Authorized Entryonly after the fingerprint looks right. Copy theauthorized_keys lineand check the options prefix before installing it on a server. - Use
Derivation Tracewhen the result came from an unexpected path or a warning appears. Unsupported PEM, encrypted PKCS#8 input, malformed OpenSSH data, and missing keys need different fixes. - Compare the displayed SHA-256 fingerprint with a trusted source before using the generated line for access.
Interpreting Results:
SHA-256 fingerprint is the main identity check. It is calculated from the public key blob and is the value to compare with a trusted record or a known-good command output. MD5 fingerprint is included for older references, but it should not be the only value you compare when SHA-256 is available.
Derivation path explains how the public key was obtained. openssh_private_key means a supported public key was read from an OpenSSH private-key container. rsa_private_pem means the public half was derived from RSA private key material. public_key_line means the input already contained a supported public key line.
Keys ignored is a safety cue. A value above zero means more than one supported key was found, but only the first one was used for the fact sheet and authorized-entry output. Split the input and run the intended key alone when that count surprises you.
The easiest result to overread is the rebuilt line. A clean authorized_keys line is syntactically useful, but login can still fail because the key was added to the wrong account, the destination file has bad ownership or permissions, a restriction blocks the intended action, or server policy rejects the key type.
Technical Details:
SSH public-key authentication compares a public key blob, not the surrounding comment or the name of the file it came from. RFC 4253 describes the binary public-key structure as a string naming the key format followed by key-specific data. For RSA, that includes the public exponent and modulus; for Ed25519 and ECDSA forms, the key type and public bytes identify the algorithm and key material.
The authorized keys text line wraps that public blob in operational context. OpenSSH documents the line as optional options, key type, base64-encoded key, and comment. The options can restrict how a successful key authentication may be used, while the comment is for humans. Neither one changes the public key blob used for the standard SSH fingerprints.
Transformation Core
| Input source | Accepted form | Result path | Main output |
|---|---|---|---|
| OpenSSH private key | Supported openssh-key-v1 private-key material. |
openssh_private_key |
First public key blob inside the private-key container. |
| RSA private key PEM | Readable RSA private-key PEM in a supported unencrypted form. | rsa_private_pem |
An ssh-rsa public blob built from the RSA exponent and modulus. |
| Public key line | ssh-rsa, ssh-ed25519, or supported NIST ECDSA line. |
public_key_line |
The decoded public blob, its bit length, and a rebuilt authorized-entry line. |
The key fact sheet and authorized-entry output depend on the same public blob. The fingerprint math is compact, but the distinction between blob and line is important enough to show formally.
The formulas explain why the two SSH fingerprints stay stable when only the restrictions or comment change. The optional Line SHA-256 prefix is different because it hashes the full generated text line; it is a change-detection hint for that line, not a standard SSH key fingerprint.
| Field | Meaning | Common check |
|---|---|---|
Key type |
The SSH public-key algorithm token. | Confirm it matches the server policy you expect. |
Bits |
Estimated or decoded public key size for the supported type. | Use it as an inventory clue, not as a complete strength assessment. |
SHA-256 fingerprint |
Base64 SHA-256 digest of the public key blob. | Compare this first against a trusted source. |
authorized_keys line |
Options prefix, key type, base64 key, and optional comment joined into one server-file line. | Check restrictions and account placement before installation. |
Privacy Notes:
Extraction and fingerprinting run in the browser, so the key does not need to be submitted to a remote service for processing. Treat live private-key material as sensitive even when using local extraction.
- Changed field values can appear in the page URL, so do not share the URL after pasting a private key, restriction string, or sensitive comment.
- Prefer public key lines when they are enough for fingerprint checks.
- Use disposable test material or a controlled local command when production private-key exposure would be unacceptable.
Worked Examples:
Checking a public key line before install
A pasted ssh-ed25519 line with one trailing comment should show Key type ssh-ed25519, Bits 256, Derivation path public_key_line, and Keys ignored 0. Compare SHA-256 fingerprint with the trusted request before copying the generated line into the server account.
Recovering an RSA public entry
A readable RSA private key PEM can produce an ssh-rsa public entry. If you add no-port-forwarding in authorized_keys options and set Comment override to deploy@web01, the generated line changes, but the SSH fingerprints remain tied to the derived public blob.
Multiple keys in one paste
A handoff note may contain two public key lines. The fact sheet uses the first supported line and reports the rest under Keys ignored. Split the note and rerun the exact key you meant to review before installing anything.
FAQ:
Which SSH key formats work here?
The supported paths are OpenSSH private keys, readable RSA private key PEM input, and public key lines for ssh-rsa, ssh-ed25519, and supported NIST ECDSA forms.
Why did an encrypted private key fail?
Encrypted PKCS#8 and unsupported encrypted PEM forms are not opened because the page does not prompt for a passphrase. Export or paste the public key line instead.
Why do the fingerprints stay the same after I change the comment?
The SSH fingerprints are calculated from the public key blob. Comments and restrictions change the full text line, but they do not change the public key bytes.
Is the line hash the same as the SSH fingerprint?
No. Line SHA-256 prefix hashes the generated line text, so it changes when options or comments change. Use SHA-256 fingerprint for key identity.
Why can login fail when the fingerprint matches?
A matching fingerprint proves the public key identity only. Check the account, file ownership, file permissions, restrictions, and server key policy when authentication still fails.
Glossary:
- Public key blob
- The decoded SSH public-key bytes that are fingerprinted and compared during authentication.
- authorized_keys line
- The server-file line made from optional restrictions, a key type, a base64 key, and an optional comment.
- Derivation path
- The route that produced the current result, such as a private-key source or direct public-key line.
- Fingerprint
- A compact digest used to compare one public key blob with another.
- Options prefix
- Comma-separated restrictions placed before the key type in an authorized keys file.
References:
- RFC 4253: The Secure Shell (SSH) Transport Layer Protocol, IETF, January 2006.
- sshd(8) Manual Page, OpenBSD.
- FIPS 180-4: Secure Hash Standard, National Institute of Standards and Technology, August 2015.