Secure Shell (SSH) Public Key Extractor

SSH access handoffs often arrive as a public key line, a private key file, or a copied block from an old deployment note. The server does not need the private key. It stores a public key and asks the connecting client to prove that it still controls the matching private half. That proof is why a public key can be copied into an account record, while the private key must stay protected.

The useful identity in that handoff is the public key blob: the decoded SSH bytes that describe the key type and key material. File names, comments, and server restrictions help people manage access, but they are not the same thing as the key identity. A fingerprint gives administrators a compact way to compare one public key blob with another without reading a long base64 string by eye.

Key type token

The visible SSH algorithm name, such as ssh-ed25519, ssh-rsa, or an ecdsa-sha2-* curve token.

Public key blob

The binary SSH public-key structure that gets fingerprinted and compared during authentication.

Fingerprint

A digest of the public key blob, usually shown as SHA-256 for modern checks and sometimes as MD5 for older records.

authorized_keys line

One server-file line made from optional restrictions, the key type token, the base64 public key, and an optional comment.

Extracting a public key from private-key material is common when the matching .pub file is missing, when a deploy key needs to be reviewed before rotation, or when an access request includes a private-key export instead of the safer public line. It is still better to work from a public line when one is available, because private-key text can grant access if it leaks.

Options such as forced commands or disabled forwarding belong before the key in an authorized_keys file. They can make a valid key less capable on that account, but they do not change the fingerprint because the fingerprint is based on the public key blob. The trailing comment is even less authoritative: it helps humans identify a key, but it is not used as cryptographic identity.

A matching fingerprint is a strong check that two public key blobs are the same. It does not prove that the private key is stored safely, that the server will accept the algorithm, that the destination account is correct, or that file ownership and permissions are ready for login.

How to Use This Tool:

Use the least sensitive key text that answers your question. A public key line is enough for most fingerprint checks and server-entry rebuilds.

1. Paste text into SSH key input, drop one supported key file onto the field, or choose Browse SSH key file. Supported file extensions include .pub, .pem, .key, and .txt.
2. For private-key input, use an OpenSSH private key or a readable RSA private key PEM. If the warning says encrypted PKCS#8 or unsupported PEM, paste the public key line instead or export the public half with a trusted local SSH command.
3. Add authorized_keys options only when the server entry needs restrictions such as no-port-forwarding or a forced command="...". Check the option text carefully because it is prepended as policy text.
4. Set Comment override when the final line needs a specific owner or host note. Leave it blank to keep a detected public-line comment or to produce a private-key-derived line without a comment.
5. Read Key Fact Sheet before copying anything. Confirm Key type, Bits, SHA-256 fingerprint, Derivation path, Keys detected, and Keys ignored.
6. Open Authorized Entry after the fingerprint matches the trusted record. Review Options prefix, Comment token, and the full authorized_keys line before placing it on a server.
7. Use Derivation Trace when a warning appears or the result is not the key you expected. Multiple detected keys, malformed OpenSSH data, and unsupported private-key formats require different fixes.

Interpreting Results:

SHA-256 fingerprint is the main comparison value for key identity. Compare it with a trusted ticket, inventory record, or known-good command output. MD5 fingerprint is useful when an older reference only has the colon-separated form, but it should not replace the SHA-256 check when SHA-256 is available.

• Derivation path tells you how the public blob was obtained. public_key_line means the input already contained a supported public key line, openssh_private_key means the public blob came from an OpenSSH private-key container, and rsa_private_pem means an RSA public blob was derived from private key values.
• Keys ignored deserves attention. A value above 0 means the fact sheet and authorized entry use only the first supported key found in the input.
• Line SHA-256 prefix is a hash clue for the generated text line. It changes when options or comments change, so it is not the same as the SSH public key fingerprint.

Do not treat a clean authorized_keys line as proof that login will work. Authentication can still fail because the line was added to the wrong account, the file has unsafe permissions, the server rejects the key type, or an option blocks the intended command.

Technical Details:

SSH public-key data is encoded as typed binary fields. RFC 4253 defines the RSA public key format as an SSH string containing ssh-rsa, followed by multi-precision integers for the public exponent and modulus. RFC 5656 defines the ECDSA family around curve-specific names such as ecdsa-sha2-nistp256. RFC 8709 adds ssh-ed25519 as an SSH public key algorithm for signing.

An authorized_keys file line is text around that binary public key. OpenSSH documents the user-authorized form as optional comma-separated options, key type, base64-encoded key, and comment. The key type and base64 value identify the public blob; restrictions and comments change the line text but not the cryptographic public key identity.

Transformation Core

The fingerprint calculations operate on the decoded public key blob, not on the pasted line as text. The generated server line is built after that blob is known.

For RSA, the bit count comes from the modulus length. For Ed25519 it is fixed at 256 bits. For supported ECDSA lines, the curve name maps to 256, 384, or 521 bits. Those values are useful inventory clues, but they should not be compared as if every algorithm's bit length meant the same security margin.

Privacy Notes:

Key extraction, blob decoding, fingerprinting, and line rebuilding happen in the browser after the page has loaded. The key text does not need to be submitted to a remote service for these checks, but private-key material still deserves the same care as a password or deploy credential.

• Prefer a public key line when it is enough for the fingerprint or server-entry check.
• Do not share the page URL after pasting private-key text, restrictions, or sensitive comments, because field values can be reflected in the URL state.
• Use disposable test keys or a trusted local command when production private-key exposure would be unacceptable.

Advanced Tips:

• Use a public key line instead of a private key whenever SHA-256 fingerprint, MD5 fingerprint, or an authorized_keys line is all you need.
• Split copied notes that contain more than one supported key. The result uses the first detected key, so Keys ignored above 0 means another line needs a separate pass.
• Review authorized_keys options as server policy, not as key identity. A forced command, source address rule, or forwarding restriction can block a login that has a matching fingerprint.
• Keep Comment override short and operational, such as deploy@web01 or a ticket reference. It helps later cleanup, but it does not prove ownership.
• When private-key parsing fails, compare the warning with Derivation Trace. Encrypted PKCS#8, malformed OpenSSH data, and unsupported PEM input each call for a different recovery path.

Worked Examples:

Reviewing an Ed25519 handoff

A request includes one ssh-ed25519 public key line with a trailing deploy@laptop comment. The result should show Key type as ssh-ed25519, Bits as 256, Derivation path as public_key_line, and Keys ignored as 0. Compare SHA-256 fingerprint with the approved record before copying the authorized_keys line.

Rebuilding an RSA server line

A 3072-bit unencrypted RSA private key PEM can produce an ssh-rsa public entry. If authorized_keys options contains no-port-forwarding and Comment override is set to deploy@web01, the generated authorized_keys line includes both pieces of text, while SHA-256 fingerprint and MD5 fingerprint remain tied to the same public blob.

Catching a pasted key list

A migration note may contain an old RSA line followed by a newer Ed25519 line. When Keys detected is 2 and Keys ignored is 1, the fact sheet describes only the first supported key. Split the note and run the intended line by itself before adding access.

Handling an encrypted private key warning

If the warning says an encrypted PKCS#8 private key is not supported, the page has not opened the key material with a passphrase. Use the existing .pub file or run a local key export command, then paste the public line and verify the resulting SHA-256 fingerprint.

FAQ:

Glossary:

Public key blob

The decoded binary SSH public-key structure used for fingerprints and authentication comparison.

Key type token

The SSH algorithm name at the start of a public key line, such as ssh-ed25519 or ssh-rsa.

Derivation path

The reported route that produced the result, such as a public key line or private-key-derived public blob.

Options prefix

Comma-separated restrictions placed before the key type in an authorized_keys file.

Line SHA-256 prefix

A short SHA-256 hash prefix for the generated text line, useful for line-change checks but not for SSH key identity.

References:

• RFC 4253: The Secure Shell (SSH) Transport Layer Protocol, RFC Editor, January 2006.
• RFC 5656: Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC Editor, December 2009.
• RFC 8709: Ed25519 and Ed448 Public Key Algorithms for the Secure Shell Protocol, RFC Editor, February 2020.
• ssh-keygen(1) Manual Page, OpenBSD.
• sshd(8) Manual Page, OpenBSD.
• How to extract a public key from an SSH private key, Simplified Guide.
• How to copy an SSH public key to a server, Simplified Guide.