OpenSSH Public Key Format: The Three Fields and What They Mean

Q: Is the public key format the same for ed25519 and RSA?

Yes - both are one line of ` `. The algorithm field tells the server what type of key it is, and the base64 blob has the key material in the algorithm's format.

Q: What is the comment field for?

Freeform. The default is `user@hostname` from the machine that generated the key. Most teams set a clear convention - email address or `service-name:purpose` - to make it obvious which key is which in `authorized_keys`.

An OpenSSH public key is one line of text: <algorithm> <base64-key> <comment>. The algorithm is ssh-ed25519 or ssh-rsa. The base64 blob is the encoded key. The comment is freeform and usually an email or a hostname. The team that adds keys to authorized_keys and GitHub reads this format every day without thinking about it.

The three fields, byte by byte
Where this format is used
Generating a public key from a private key
Inspecting and verifying a public key
How this fits the rest of the stack
FAQ

The three fields, byte by byte

A .pub file looks like:


ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgY5HL8J3oFd4f4f4f4f you@workstation

Field 1: the algorithm. ssh-ed25519 for ed25519, ssh-rsa for RSA, ecdsa-sha2-nistp256 for ECDSA P-256, etc. The team that runs older systems sees ssh-rsa on most legacy boxes.

Field 2: the base64 blob. This decodes to the binary key material. The team that builds a deploy system can extract just this field and treat it as opaque - the rest of the system does not need to know the key type.

Field 3: the comment. Freeform. Defaults to user@hostname from the machine that generated the key. The team that manages many developers sets a clear convention here - [email protected] works.

Where this format is used

~/.ssh/id_ed25519.pub on the client machine.
~/.ssh/authorized_keys on the server, one key per line.
GitHub / GitLab / Bitbucket SSH key settings.
SSH certificates issued by a CA (with a slightly extended format).
known_hosts (but a different shape - host key, not user key).

The format is stable. The same line you copy from id_ed25519.pub works in every one of these places.

Generating a public key from a private key

If you have a private key but lost the .pub:


ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub

The -y flag means “yield the public key”. The output goes to stdout, so the redirect writes the .pub file. The team that recovers from a partial backup uses this to recreate the public half without regenerating the key.

If the private key is passphrase-protected, ssh-keygen prompts for the passphrase. Without the correct passphrase, you cannot derive the public key.

Inspecting and verifying a public key

Fingerprint:


ssh-keygen -lf ~/.ssh/id_ed25519.pub

Output: <bits> <fingerprint> <comment>. The fingerprint is a SHA-256 hash by default (older OpenSSH versions defaulted to MD5; -E md5 to force the old format).

Visual randomart: ssh-keygen -lvf ~/.ssh/id_ed25519. Useful for confirming a key matches over a phone call - the randomart is short enough to compare verbally.

The team that confirms a deploy key is the right one before adding it to authorized_keys checks the fingerprint first. The fingerprint is the safe comparison - never the full key.

FAQ

Is the public key format the same for ed25519 and RSA?

Yes - both are one line of <algorithm> <base64> <comment>. The algorithm field tells the server what type of key it is, and the base64 blob has the key material in the algorithm’s format.

Can a public key be derived from a private key?

Yes. The public key is mathematically derived from the private key - the private key contains all the information needed to compute the public key. That is why losing the .pub file is recoverable, but losing the private key is not.

What is the comment field for?

Freeform. The default is user@hostname from the machine that generated the key. Most teams set a clear convention - email address or service-name:purpose - to make it obvious which key is which in authorized_keys.

Why is the fingerprint useful?

The fingerprint is a SHA-256 hash of the public key. It is short enough to compare over a phone call or paste into a chat. The team that confirms a key is the right one before adding it to a server uses the fingerprint, not the full key, because the fingerprint is short and the full key is hundreds of characters.

Can I have multiple public keys in authorized_keys?

Yes - one per line. Each line authenticates a different key. The server accepts any of them. The team that has many developers on one server has many lines, one per developer or per developer-machine.

How this fits the rest of the stack

For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.

Useful related references: