OpenSSH Private Key

What OpenSSH private keys are and why they matter

An OpenSSH private key is the secret half of an SSH key pair. It is not just a file, it is a bearer credential for proving identity in key-based authentication, so anyone who obtains it can act as the associated SSH principal until the key is revoked or replaced.

Because the private key itself confers access, its security depends on where it is stored, who can read it, and whether it is protected at rest with strong local controls. The associated public key may be widely distributed, but the private half must remain tightly controlled.

How OpenSSH private keys are used in authentication

In SSH authentication, the client proves possession of the private key by completing a cryptographic challenge. The server verifies that proof against the corresponding public key, which is why the private key functions as an identity-bearing secret rather than a normal data file.

This model is useful because it avoids sending the secret over the network, but it shifts the main security problem to storage and handling. If the private key is copied from a workstation, build host, container image, backup set, or shared directory, the attacker does not need to break SSH itself.

The practical consequence is that OpenSSH private keys often sit at the intersection of authentication, privileged access, and secret management. They may be used by administrators, automation, deployment jobs, jump hosts, or scripts, and those contexts affect both exposure and blast radius.

Where exposure usually comes from

OpenSSH private keys are commonly exposed through filesystem misconfiguration, repository leakage, image-layer leakage, unsafe backups, or accidental inclusion in shared artifacts. A leaked key can persist for a long time if it is not discovered, and that is especially dangerous when it is reused across hosts or services.

Exposure also becomes more likely when key material is copied into convenience tools or wrapped into automation without clear ownership. When access is broad or the storage location is poorly governed, the key can become a durable path to impersonation rather than a tightly controlled authenticator.

For deeper guidance on discovery, rotation, and governing SSH material across hosts and bastions, see the SSH Key and SSH Certificate Management Guide.

What defenders should do with OpenSSH private keys

Defensive handling starts with inventory: know where keys live, which principals they unlock, and whether any are tied to production access, automation, or privileged accounts. That inventory should extend beyond interactive users to scripts, pipelines, and systems that authenticate without human involvement.

Storage should minimise readable copies, and high-value keys should be treated as secrets with tight access boundaries, strong encryption where appropriate, and clear revocation paths. If a key is suspected to have been exposed, the response is not only to replace the file, but to assess the SSH access it enabled and the systems that trusted it.

For cases where private keys appear in repositories or other source-controlled material, the Private Keys in Repositories Guide explains how to find, revoke, and remove them safely. For broader credential discovery and detection patterns, the MITRE ATT&CK T1552 Unsecured Credentials Guide is useful for understanding where private keys commonly surface.

Risk and Threat Considerations

OpenSSH private key exposure creates a direct impersonation risk. If an attacker obtains the key, they can often authenticate as the associated principal without needing passwords, phishing, or interactive compromise, which makes the key a high-value target for persistence and lateral movement.

Failure mechanism: The key is copied from an endpoint, repository, backup, image, or shared path, then reused to establish authenticated SSH sessions until defenders detect the leak and revoke trust in that key.

Impact: The attacker can access hosts, execute commands, move through administrative paths, and preserve access until rotation or revocation closes the entry point.

Practitioner Guidance

Why practitioners should care: Treat SSH private keys as long-lived authentication material, not as ordinary files. The important governance question is who owns the key, where it is allowed to exist, and what business function depends on it. If the key supports privileged administration or automation, its compromise should be handled as an access incident, not just a secret hygiene issue.

What to watch for: Reused keys, orphaned keys, keys stored outside approved secret stores, and keys embedded in images or repositories deserve immediate review. When an SSH key has wide reuse or unclear ownership, the safest assumption is that compromise would have broad operational effect.

Practitioner takeaway: The value of an OpenSSH private key is not its file format, it is the authority it conveys, so rotation and revocation planning should be built around the access it unlocks.

Related resources from NHI Mgmt Group

• How should security teams respond when a private key leaks publicly?
• How should security teams use private_key_jwt for OAuth client authentication?
• When should organisations choose private_key_jwt over a client secret?
• What do teams get wrong about private_key_jwt in MCP flows?