ssh-keygen creates and manages SSH key pairs, host keys, and key conversions for secure authentication. It generates public and private keys, can change passphrases, and can inspect fingerprints. Protect private keys with strong permissions and passphrases, and rotate compromised or weak keys promptly to prevent unauthorised access.
What ssh-keygen actually does
ssh-keygen is the OpenSSH utility for creating and managing ssh key pairs, host keys, and related key material. In practice, it is the tool you use to generate a public/private key pair, change a private key passphrase, inspect fingerprints, and convert keys between supported formats. Its value is not just generation, but the lifecycle management around SSH authentication.
That lifecycle matters because SSH keys are identity-bearing material. A private key can authenticate a user, service, or host without a password prompt, so the operational question is not only “was the key created?” but “who controls it, where is it stored, and how quickly can it be replaced if it is exposed or becomes obsolete?”
ssh-keygen also supports host key administration, which is important on the server side. Host keys let clients verify that they are connecting to the intended SSH server, while user keys let a person or process prove possession of the private key. Fingerprints give operators a concise way to compare and verify key identity without handling the full key blob.
How key generation and conversion affect security
Key generation is only the first step. ssh-keygen produces asymmetric key pairs, which means the public key can be shared and the private key must remain secret. When you set or change a passphrase, you are adding a second layer of protection for the private key file itself. That matters most when the file might be copied, backed up, or stored on an endpoint with mixed trust.
The format conversion functions are useful when moving between SSH implementations or key representations, but they should be treated as a change-control step, not a convenience feature. Converting or rewrapping a key can alter how it is stored, protected, or consumed by tooling, so teams should confirm that the resulting file still matches the intended authentication path and access policy.
For operational hygiene, ssh-keygen is best understood as part of the broader key lifecycle rather than a one-time setup command. The companion guidance in SSH Key and SSH Certificate Management Guide is especially useful when you need to govern sprawl, remove orphaned keys, or decide when ssh certificate are a better control than unmanaged long-lived keys.
How to use ssh-keygen safely in real environments
Most production failures around SSH keys come from weak storage and weak lifecycle handling, not from the algorithm itself. A private key with broad file permissions, no passphrase, or no ownership tracking can become a durable access path long after the original operator forgot about it. That is why key creation should be paired with permission hardening, inventory, and revocation planning from the start.
When a key is compromised, suspect it as a credential incident, not a simple configuration issue. The right response is to replace the key, remove the old public key from authorized access lists, and review where the private key may already have been used. If the key was reused across systems, the blast radius can be much wider than a single account or host.
For baseline control design, NIST SP 800-53 Rev 5 Security and Privacy Controls supports the access control and identification-and-authentication discipline around SSH usage, while NIST SP 800-57 Key Management is the better reference when the issue is private key lifecycle, protection, and rotation discipline.
Risk and Threat Considerations
SSH keys create fast, low-friction access, which is exactly why they are attractive to attackers when they are exposed, reused, or left on systems with weak permissions. The main risk is not the existence of key-based authentication, but the persistence of access after the human owner has moved on, the host has changed, or the key has leaked into backups, scripts, or build artifacts.
Failure mechanism: A stolen or copied private key can authenticate without triggering password-based friction, and reused keys can give an attacker repeatable access across multiple systems. Weak host key hygiene can also undermine trust in the server a client believes it is reaching.
Impact: Unauthorized SSH access can lead to interactive shell compromise, lateral movement, data theft, configuration tampering, or covert persistence. If the same key is accepted in multiple places, a single compromise can become a cross-environment incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-57 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 keys are authenticators whose lifecycle must be controlled. |
| IA-2 — Identification and Authentication (Organizational Users) | User SSH keys authenticate organizational users into systems. | |
| IA-9 — Service Identification and Authentication | SSH keys often authenticate services, automation, and non-human actors. | |
| Recommendation — Enforce lifecycle controls for SSH keys, including issuance, protection, rotation, and revocation. Require strong identification and authentication for SSH-based administrative access. Apply service authentication controls to non-human SSH access paths. | ||
| NIST SP 800-57 | Key Management | SSH keys need lifecycle, protection, and rotation discipline. |
| Recommendation — Manage SSH key generation, storage, rotation, and destruction as formal key lifecycle events. | ||
| CIS Controls v8 | 5 — Account Management | SSH keys often represent account access and require ownership and revocation. |
| Recommendation — Inventory SSH key-backed access and remove stale or orphaned keys promptly. | ||
Practitioner Guidance
What to verify: Treat every SSH key as an inventory item with an owner, purpose, and expiry or review date. Verify that the private key is protected by restrictive file permissions, that passphrases are used where operationally feasible, and that the corresponding public key appears only on systems that truly need it.
Decision rule: If the key is shared, long-lived, or difficult to attribute to a specific owner or workload, treat that as a governance problem and replace it with tighter scoping or a more manageable trust pattern. If the key can unlock production access, rotation and revocation planning should be as deliberate as for any other privileged credential.
Practitioner takeaway: ssh-keygen is easy to use, but SSH key security is won or lost in management discipline, not in the command itself, so the key question is always whether the resulting private key has bounded, attributable, and revocable access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org