SSH Public Key Decoder
Decode SSH public key details, fingerprint, and comments.
SSH Public Key Decoder
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The SSH Public Key Decoder reads an SSH public key line — the familiar ssh-rsa AAAA... or ssh-ed25519 AAAA... format found in authorized_keys files and public key files — and reports its algorithm type, key size, and any comment field, without requiring you to parse the base64 body by hand.
- An SSH public key line has three space-separated parts: an algorithm identifier prefix, a base64-encoded body containing the algorithm-specific key parameters (encoded per RFC 4253's key-blob format), and an optional trailing comment — typically a label like a username or hostname, purely for the reader's benefit and not used by SSH itself for anything functional.
- This tool complements the SSH Fingerprint Generator rather than duplicating it: this tool decodes the key's own structural metadata (type, size, comment); the Fingerprint Generator instead hashes the key down to a short, comparable value used specifically for out-of-band host identity verification.
How It Works
- The key line is split into its three components: the algorithm prefix, the base64-encoded body, and the optional comment.
- The algorithm prefix identifies the key type (ssh-rsa, ssh-ed25519, and similar) directly.
- The base64 body is decoded to determine the key's size — for RSA, derived from the encoded modulus length; for Ed25519, always a fixed 256-bit key by the algorithm's own definition.
- The comment field, if present, is extracted as-is — it carries no cryptographic meaning and exists purely as a human-readable label.
Usage
- Paste the SSH public key line you want to decode.
- Run the decode.
- Review the reported algorithm type, key size, and comment.
- Use this to confirm the key's properties before trusting it, auditing it, or troubleshooting an authentication issue.
Examples
- Decoding a key found in a server's authorized_keys file to identify its algorithm and size as part of a security audit of legacy access.
- Confirming a key pasted from a colleague matches the expected algorithm (e.g. Ed25519) before adding it to an authorized_keys file.
- Checking the comment field on an old key to identify whose access it represents, before deciding whether it's still needed.
- Verifying a public key copied from a generation tool decodes without error, catching a copy-paste truncation before it causes a confusing authentication failure.
Real-World Use Cases
- Confirming what algorithm and key size an existing public key actually uses before deciding whether it meets a current security policy.
- Reading the comment field on a key found in an authorized_keys file to identify which person or automation it was originally issued to, when the file's history isn't otherwise documented.
- Verifying a public key was copied correctly (no truncation or line-wrapping corruption) by confirming it decodes cleanly to a sensible algorithm and size.
- Auditing a server's authorized_keys file to check for legacy or weak key types that should be rotated to something stronger.
Best Practices
- Periodically audit authorized_keys files for outdated or unexpectedly weak key types, using the decoded algorithm and size to flag anything below your current minimum standard.
- Use the comment field consistently when generating keys (e.g. username@purpose) so a decoded key's origin is identifiable later, long after the original context is forgotten.
- Confirm a key decodes cleanly before troubleshooting further into an authentication failure — a truncated or corrupted key line is a common, easy-to-miss root cause.
- Don't rely on a key's comment field for any actual security decision — it's an unauthenticated label, not a verified property of the key itself.
Common Mistakes
- Trusting the comment field as if it were a verified attribute of the key — anyone can set any comment when generating or editing a key; it's for human reference only.
- Assuming all SSH public keys are the same size — Ed25519 keys are always a fixed, small size, while RSA key size varies (2048, 4096-bit, and others), and comparing the two directly as if size alone indicated strength is a category error given their different underlying algorithms.
- Not noticing a key line has been corrupted by line-wrapping or truncation during copy-paste, then troubleshooting an authentication failure as if it were a permissions or configuration issue instead.
- Confusing this tool's purpose with the SSH Fingerprint Generator — decoding structure and computing a fingerprint are different operations serving different needs.
Limitations
- This tool decodes the structural metadata of a public key you provide; it does not verify that the key is actually authorized for anything or check it against any server's configuration.
- It reports what the key's comment field contains as-is; it cannot verify the comment is accurate, since the comment carries no cryptographic authentication of its own.
- This tool does not compute a fingerprint — use the SSH Fingerprint Generator specifically for that purpose.
Technical Reference Guide
- The SSH public key file format, including the algorithm-prefix-plus-base64-body-plus-comment structure this tool decodes, is defined by RFC 4253, Section 6.6.
- The Ed25519 key encoding within this format is specified by RFC 8709, which defines Ed25519's use within the SSH protocol specifically.
- The comment field is a convention documented in OpenSSH's own key file handling rather than a strict requirement of RFC 4253 itself, which is why its presence and content are entirely optional and unverified.
FAQ
What's the difference between this tool and the SSH Fingerprint Generator?
This tool decodes a public key's own structural fields — algorithm, size, comment. The Fingerprint Generator instead hashes the key down to a short value used specifically to verify a host's identity out-of-band on first connection. They serve different, complementary purposes.
Is the comment field part of the key's security?
No — it's an unauthenticated, human-readable label, typically a username or hostname, purely for reference. It carries no cryptographic weight and can be set to anything when the key is generated or edited.
Why do Ed25519 keys always show the same size?
Ed25519 is defined with a fixed key size (256 bits) as part of the algorithm itself, unlike RSA, where key size is a configurable parameter chosen at generation time (2048, 4096-bit, and so on).
My key fails to decode — what's likely wrong?
The most common cause is the key line being truncated or corrupted during copy-paste, often from unexpected line-wrapping. Confirm you've copied the entire single-line key, including the full base64 body.
Can I tell if a key is still in active use from decoding it?
No — decoding reveals the key's own structural properties, not whether or where it's currently authorized. Check the relevant server's authorized_keys file directly to confirm active use.
Should I be concerned about an old RSA-2048 key I find during an audit?
RSA-2048 is still considered acceptable by most current guidance, though Ed25519 or RSA-4096 offer a stronger margin for keys expected to remain in use for a long time — treat this as a rotation-priority decision, not necessarily an urgent one.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools