An RSA SSH key is a cryptographic credential pair used to authenticate access over SSH. The public key can be shared, but the private key must remain protected because it proves identity and grants access. In practice, private keys should be stored in controlled systems with monitoring, rotation, and restricted access.
Expanded Definition
An RSA ssh key is a public-private cryptographic credential pair used to prove identity during SSH authentication. The public key may be distributed to the target system, while the private key remains the sensitive secret that must be protected, monitored, and eventually rotated. In NHI governance, the key is not just an access artifact but an identity binding that often stands in for a person, workload, or automation path.
Usage is still evolving across vendors, but the security meaning is consistent: the private key functions as a long-lived secret, and the public key is only useful when paired with an authorised trust relationship. This makes RSA SSH keys different from passwords because they can be provisioned without human memorisation, yet they can also persist unnoticed for long periods if inventory and revocation are weak. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need to identify, protect, and recover identity assets as part of broader resilience.
The most common misapplication is treating the private key like a normal configuration file, which occurs when teams copy it into code repositories, image layers, or unmanaged developer laptops.
Examples and Use Cases
Implementing RSA SSH keys rigorously often introduces lifecycle overhead, requiring organisations to weigh automation convenience against the cost of inventory, rotation, and emergency revocation.
- Administrative access to Linux servers uses an RSA SSH key stored in a managed vault, with the public key installed only on approved hosts.
- A CI/CD pipeline authenticates to deployment targets with an RSA SSH key so build systems can execute unattended tasks without shared passwords.
- A third-party managed service connects over SSH using a dedicated key pair, with access limited by host rules and scheduled review.
- Legacy environments still rely on RSA SSH keys where passwordless login is required, but the private key is wrapped in strong operational controls and monitored for reuse.
These patterns are easier to govern when the organisation can see where keys live and how they are used. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why ssh key sprawl persists. For implementation guidance on modern service identity handling, teams often pair key governance with NIST Cybersecurity Framework 2.0 outcomes around asset management and access control.
Why It Matters in NHI Security
RSA SSH keys matter because they are often durable, reusable credentials that can outlive the systems and teams that created them. When a private key leaks, an attacker may gain direct SSH access without triggering password resets or interactive MFA workflows. That is especially dangerous in NHI environments where keys are used for service accounts, automation runners, and privileged maintenance paths. The governance problem is not RSA itself, but the operational tendency to leave keys unrotated, undocumented, and broadly trusted.
NHIMG research shows that 71% of NHIs are not rotated within recommended time frames and that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, a pattern that is highly relevant to SSH key handling. The Ultimate Guide to NHIs also reports that 91.6% of secrets remain valid five days after notification, which illustrates how slowly many environments recover once exposure is detected. Organisational controls should therefore focus on discovery, rotation, and fast revocation, not just key creation.
Organisations typically encounter the full impact of an RSA SSH key only after a key is stolen, at which point access review and revocation become operationally unavoidable.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling, rotation, and exposure risks for SSH private keys. |
| NIST CSF 2.0 | PR.AC-1 | Identity and credential management apply directly to SSH key-based authentication. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires strong identity verification and minimized implicit trust for SSH access. |
Treat each RSA SSH key as an access credential, restrict issuance, and validate who or what may use it.
