A -----BEGIN OPENSSH PRIVATE KEY----- block is the OpenSSH-native key format introduced in OpenSSH 7.8 (2018). It replaced the old PEM format that began with -----BEGIN RSA PRIVATE KEY-----. The team that uses OpenSSH 7.8+ on Linux/macOS/Windows 10+ has these keys by default with ssh-keygen -t ed25519.
Table of contents
- What the BEGIN OPENSSH PRIVATE KEY header means
- How to generate one
- Converting from PEM to OpenSSH and back
- Inspecting a key without loading it
- How this fits the rest of the stack
- FAQ
What the BEGIN OPENSSH PRIVATE KEY header means
The block is a textual wrapper around a binary key blob. The header is -----BEGIN OPENSSH PRIVATE KEY-----, the footer is -----END OPENSSH PRIVATE KEY-----. Between them is a base64-encoded blob that decodes to a structured binary record with the public key, the private key, and a comment.
The file lives at ~/.ssh/id_ed25519 (or whatever -f you passed to ssh-keygen). The .pub companion has a single line: the algorithm, the base64 public key, and a comment.
The format is documented in the OpenSSH source tree (PROTOCOL.key). The team that has been using PEM-format RSA keys from older guides has these as the new default since 2018.
How to generate one
The default path is ed25519:
ssh-keygen -t ed25519 -C "[email protected]"
This writes ~/.ssh/id_ed25519 (private, mode 600) and ~/.ssh/id_ed25519.pub (public, mode 644). The comment is the email-ish string after -C.
To use a custom path: ssh-keygen -t ed25519 -f ~/.ssh/github_ed25519 -C "github:you". The team that has multiple services (GitHub, GitLab, a bastion) uses a separate key per service this way.
For older servers that do not support ed25519: ssh-keygen -t rsa -b 4096. RSA 4096 is the fallback. The team that has a 2010-era switch or router falls back to RSA.
Converting from PEM to OpenSSH and back
If you have an old -----BEGIN RSA PRIVATE KEY----- file, convert it to OpenSSH format:
ssh-keygen -p -m RFC4716 -f ~/.ssh/id_rsa_legacy
-m RFC4716 is the OpenSSH format. The command prompts for the old passphrase, writes the converted key back to the same path, and updates the comment.
To convert OpenSSH back to PEM (for systems that expect PEM):
ssh-keygen -p -m PEM -f ~/.ssh/id_ed25519
The team that needs to use a key with a vendor appliance that only accepts PEM runs this.
Inspecting a key without loading it
The fingerprint (useful for confirming a key is the one you expect):
ssh-keygen -lf ~/.ssh/id_ed25519.pub
This prints the key length, the fingerprint, and the comment. The team that adds a key to authorized_keys checks the fingerprint first to make sure it matches what the user shared.
For the randomart visualization (human-readable key check): ssh-keygen -lvf ~/.ssh/id_ed25519. The team that copies keys between machines uses this when paranoid.
FAQ
Why is the new format different from the old one?
The new format (OpenSSH native) bundles the public key, the private key, and a comment into a single structured record. The old PEM format was an envelope around a single key type with no comment slot. The OpenSSH format is also more extensible - new algorithms just add new record types.
Can OpenSSH read the old PEM format?
Yes. OpenSSH reads both formats transparently. The conversion is for keys you want to share with tools that expect only one format - for example, a Java application that loads a key file might require PEM.
Is the new format less secure than PEM?
No. The security of the key is the same - it is the same RSA or ed25519 math either way. The new format is more convenient because it carries the comment and the public key alongside the private key, so you do not have to track them separately.
Can I use the same key on multiple machines?
Yes, by copying the private key file (or its contents) to the other machine’s ~/.ssh/. The team that uses one key for everything copies it to every laptop and server. The trade-off: if one machine is compromised, every other machine with the key is also exposed.
Should I passphrase-protect the key?
Yes, if the machine that holds the key is at risk of physical access theft. The passphrase is local only - it does not change anything about how the key authenticates to servers, it just means the key file on disk is useless without the passphrase. The team that uses a YubiKey or a TPM for additional protection is a different (stronger) pattern.
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: