ssh-keygen is the command-line tool used to create, inspect and manage SSH key pairs. It is used for authentication and sometimes host key generation, so key type, passphrase protection and rotation matter. Weak or unprotected private keys can be stolen and reused for remote access to systems and automated accounts.
What ssh-keygen does and why it matters
ssh-keygen is the standard OpenSSH utility for creating and managing ssh key pairs. It sits at the boundary between convenience and control, because the private key it produces may become the primary credential for remote administration, automation, and host trust.
Its practical importance comes from the fact that SSH keys are often long-lived and widely reused. A private key that is generated without strong protection, stored carelessly, or left in circulation after a role changes can become a durable remote access path.
For teams managing large estates, the key-management problem is not just creation. It also includes ownership, passphrase policy, key inventory, rotation, revocation, and deciding when to use user keys versus host keys or certificates.
How ssh-keygen fits into SSH authentication
ssh-keygen supports asymmetric authentication by creating the key pair that underpins SSH public-key access. The public key is distributed to systems that should trust it, while the private key remains the sensitive secret that proves possession.
That model is useful because it avoids shared passwords, but it also concentrates risk in the private key. If the private key is copied from a laptop, build host, jump box, or automation runner, an attacker may be able to authenticate as that account without needing the original system.
SSH host keys are another important use case. They help systems identify themselves to clients, which means the tool can influence both login authentication and trust in the server’s identity across repeated connections.
When organisations want a broader governance view of SSH keys, certificates, bastions, orphaned keys and rotation, the SSH Key and SSH Certificate Management Guide is the natural companion resource.
Key generation choices that affect security
Not all SSH keys carry the same operational profile. Key type, passphrase use, storage location, and whether the key is intended for a person, a service, or a host all affect exposure and recoverability.
A passphrase adds a second barrier if the private key file is stolen, but it is only effective when the passphrase is strong and the key is handled carefully. Likewise, key rotation is only meaningful if old keys are removed from authorized locations and from any automation that still depends on them.
ssh-keygen also supports workflows that shape downstream trust, such as adding comment fields, changing passphrases, and inspecting fingerprints. Those features are small but operationally significant, because they help teams identify which key is in use and whether a presented key matches what they expect.
For organisations that want a control baseline around access control, identification and authentication, and secure configuration, the NIST control catalog provides a useful anchor point for how key-handling practices fit into broader security controls.
Lifecycle, rotation, and trust hygiene
The hardest part of SSH key management is usually not issuance, it is lifecycle control. Keys tend to accumulate in scripts, developer workstations, CI jobs, jump hosts, and old home directories long after the original purpose has ended.
That is why rotation, offboarding, and orphaned-key cleanup matter as much as generation. A keypair that is still technically valid but no longer owned, tracked, or protected is a standing access risk, especially in environments that rely on automation or shared administrative paths.
Host keys deserve the same discipline. If clients continue to trust a stale or replaced host key, trust failures can become either availability problems or, worse, opportunities for impersonation if the environment is not tightly managed.
The same lifecycle concerns align with the OWASP NHI guidance on secret leakage, overprivilege, and long-lived secrets, even when the SSH key is not associated with a classic application secret store.
How to inspect, verify, and recover from exposure
ssh-keygen is also used to inspect fingerprints and compare keys, which makes it useful during audits, incident response, and environment cleanup. When a key is suspected to be exposed, teams need to identify where it exists, where it is trusted, and whether it has already been used for remote access.
Recovery often means more than replacing a file. If a private key was compromised, the corresponding access path should be treated as potentially reusable until the key is removed from authorized locations and any dependent automation is updated.
In practice, post-exposure review should include user accounts, service accounts, CI jobs, bastion access, and any host trust relationships that depended on the key. That is especially important where the key was used for unattended automation, because the attacker does not need interactive access to keep using it.
For adversary tradecraft and detection mapping, MITRE ATT&CK is useful because stolen keys commonly support credential access, lateral movement, and persistent remote access once they are introduced into the wrong hands.
Risk and Threat Considerations
SSH keys are attractive targets because a stolen private key can bypass password prompts and enable quiet, repeatable access. The risk grows when keys are long-lived, reused across systems, or stored on endpoints and automation runners that are not tightly controlled.
Failure mechanism: An attacker or insider obtains the private key, then uses it to authenticate as the mapped user or service account from another system, often without triggering the same friction as interactive logins.
Impact: Remote access can persist until the key is removed everywhere it is trusted, and the compromise may extend to automated jobs, privileged admin paths, and host trust relationships that rely on that key.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | ssh-keygen creates and manages SSH authenticators used for access. |
| IA-2 — Identification and Authentication (Organizational Users) | SSH keys can authenticate organizational users to remote systems. | |
| IA-9 — Service Authentication | ssh-keygen is also used for non-interactive SSH authentication by services and automation. | |
| Recommendation — Manage SSH key lifecycle, rotation, and revocation as authenticators. Bind SSH key issuance to verified user identities and access approvals. Use service-specific keys and tightly control machine-to-machine SSH authentication. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | A private SSH key is sensitive access material that can be stolen and reused. |
| NHI-07 — Long-Lived Secrets | SSH keys often remain valid long after they should have been retired. | |
| Recommendation — Store private SSH keys so theft from endpoints and automation hosts is less likely. Rotate SSH keys on a defined schedule and remove stale trust entries promptly. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Stolen SSH private keys are credentials that attackers can reuse for remote access. |
| T1021 — Remote Services | SSH keys commonly support attacker use of SSH for remote access and persistence. | |
| T1078 — Valid Accounts | A stolen SSH key can enable attacker use of valid accounts without password capture. | |
| Recommendation — Hunt for exposed SSH private keys and block their reuse across systems. Monitor SSH access paths for unusual key-based logins and persistence. Treat unexpected key-based authentication as potential valid-account abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | SSH keys are tied to account access and should be removed when accounts change or end. |
| Recommendation — Tie SSH key removal to account offboarding and role changes. | ||
Practitioner Guidance
Why practitioners should care: ssh-keygen is not just a utility for creating keys, it is the point where SSH access material is born, so generation standards strongly influence later exposure. Treat the command as part of identity and access hygiene, not as a one-time setup step.
What to watch for: Look for keys without passphrases, shared keys across multiple accounts, keys that outlive the owning user or automation job, and host keys that are no longer consistent with the current environment.
Practitioner takeaway: The safest SSH key is the one you can still account for, still protect, and still retire when its purpose ends.