Seeing -----BEGIN OPENSSH PRIVATE KEY----- at the top of a key file tells you how the key is packaged. It does not tell you whether the key is RSA, ECDSA, or Ed25519.
That distinction matters when you’re checking a key, troubleshooting an “invalid format” error, or handing it to software that expects a particular encoding.
Read the header as a format label
A private key has an algorithm—the kind of key material it contains—and a serialization format—the way that material is stored. The first line identifies the format, not necessarily the algorithm.
| Header | What it usually means |
|---|---|
-----BEGIN OPENSSH PRIVATE KEY----- |
OpenSSH’s private-key format; can contain RSA, ECDSA, or Ed25519 keys |
-----BEGIN RSA PRIVATE KEY----- |
RSA-only PKCS#1 structure, commonly PEM-encoded |
-----BEGIN PRIVATE KEY----- |
Usually a PKCS#8 structure, which can hold different algorithms |
These labels aren’t interchangeable. In particular, “OpenSSH” in the first header doesn’t mean “Ed25519.” OpenSSH has used its own private-key format by default for keys generated with ssh-keygen since OpenSSH 7.8.
You can check a file’s first line with:
head -n 1 keyfile
The key’s filename isn’t a reliable substitute. A file named id_rsa might not use the format you expect, and private keys don’t require a particular extension. For a deeper look at how OpenSSH, PEM, and PKCS#8 key formats differ, compare the format label with what the receiving software supports.
Check the algorithm without exposing the private key
To identify the algorithm, have ssh-keygen derive the matching public key, then inspect its fingerprint:
ssh-keygen -y -f keyfile > /tmp/key.pub
ssh-keygen -l -f /tmp/key.pub
rm /tmp/key.pub
The public key’s type identifies the algorithm. For example, it may begin with ssh-rsa, ssh-ed25519, or ecdsa-sha2-nistp256. The fingerprint output also includes a readable algorithm label.
ssh-keygen -y prints public key material; it does not print the private key. Still, treat the original file as a secret. A private-key header is not the same thing as a public-key entry: public keys are typically single-line entries and often have a .pub filename.
Convert only when a tool requires it
Most of the time, you don’t need to change a key’s format just because its header says OPENSSH. Consider conversion when a specific older application, library, or device reports that it cannot read the format and its documentation calls for another one.
Before changing anything, make a backup. The following command rewrites the key file in place:
cp keyfile keyfile.bak
ssh-keygen -p -m PEM -f keyfile
For supported RSA or ECDSA keys, -m PEM can convert to the legacy PEM encoding; for RSA, this means PKCS#1. The -p option is for changing a passphrase, and ssh-keygen will prompt you. If you’re only changing formats, you can enter the existing passphrase again, or leave it empty if the key has no passphrase.
For a PKCS#8 container, ssh-keygen also supports:
ssh-keygen -p -m PKCS8 -f keyfile
These commands repackage a supported key. They aren’t intended to create a new key or change its underlying algorithm. Compare the public-key fingerprint before and after conversion to confirm that the same key material was preserved.
There’s an important Ed25519 caveat: don’t assume ssh-keygen -m PEM or -m PKCS8 will convert an Ed25519 key for any application that requests PEM. The limitation is specific to ssh-keygen’s conversion path, and behavior can vary by OpenSSH version and platform. Check the receiving application’s documented formats and use a suitable tool if it requires another representation.
If the key won’t load
An “invalid format” or “unsupported key format” message doesn’t always mean the key is corrupt. The software may be too old to parse OpenSSH-format keys, or it may not support the key algorithm—even if it recognizes the container.
If a compatible tool still can’t parse the file, check for damage before attempting conversion. Truncated content, changed line endings, or a copy-and-paste that lost a line can break a key. Conversion won’t repair malformed key data. For errors such as error in libcrypto, follow a key-loading troubleshooting guide rather than assuming the header is the problem.
A useful order of operations is: inspect the header, check the algorithm, confirm the target application’s supported formats, and convert only if needed. Keep a backup and compare fingerprints afterward. A format mismatch is usually fixable; changing key material unnecessarily can create a new authentication problem.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)