SSH Key and SSH Certificate Management Guide

SSH keys are among the oldest and least governed non-human credentials in most organisations. They grant shell access to servers, network devices, Git repositories and cloud instances, often with root-level privileges. A plain public key in an authorized_keys file has no expiry unless someone adds one, is rarely tied to an owner, and survives the departure of the person or system that created it. NIST IR 7966 notes that some large enterprises have hundreds of thousands or even millions of SSH user keys for automated access, often providing many more entry points onto servers than interactive user accounts do. This guide is for infrastructure, identity and security teams, and covers discovery, certificates, brokered access, automation and AI agent keys, hardening, detection and a phased roadmap.

Key takeaways

• Every authorised key is an access grant. Each authorized_keys line lets a private key holder into an account, so treat it like one: approved, owned, reviewed and removed.
• Discover before you change anything. Inventory SSH servers, authorised keys, identity keys and the trust relationships between them; NIST IR 7966 calls a full inventory of private keys infeasible, so the authorised key side is the anchor.
• Short-lived certificates remove most sprawl. Servers trust a CA instead of individual keys, but OpenSSH certificates are valid forever by default, so set lifetimes deliberately and protect the CA key.
• Broker privileged SSH. Route administrative access through a bastion or PAM gateway with strong authentication and session recording, and lock authorised keys so users cannot add their own backdoors.
• Automation and AI agent keys are NHIs. Give each its own restricted key or certificate, with an owner, a forced command, a source restriction and a rotation date, and never hand an agent a person's keys.

How SSH authentication works

SSH makes two trust decisions. The client authenticates the server with a host key, which stops a man-in-the-middle posing as the server; the server then authenticates the user or process, usually with a password, Kerberos or a public key. NIST IR 7966 recommends public key authentication for automated access because it supports command and source restrictions, and it notes that public key trust is explicit: who can reach an account can be read from the destination host, provided authorised keys are controlled.

• Identity keys: the private key the client holds. IR 7966 says identity keys for interactive users should be protected by a passphrase, but notes that keys for automated access are usually unencrypted files, so file location and permissions are the real control. The ssh-keygen manual adds that host keys must have an empty passphrase.
• Agent forwarding: lets a remote host use your local agent for onward connections. The ssh_config manual warns that users able to bypass file permissions on the remote host can use the forwarded agent to authenticate with your identities, even though they cannot extract the key.
• Key types: current ssh-keygen generates Ed25519 by default and supports FIDO-backed ed25519-sk and ecdsa-sk keys. OpenSSH 10.0 (April 2025) removed DSA support entirely.

The risks

NIST IR 7966 groups SSH vulnerabilities into seven categories, most of them governance failures rather than cryptographic weaknesses.

• Key sprawl and unknown trust: keys copied to many servers and never removed. IR 7966 says many organisations do not know how many keys grant access or who holds copies.
• Stolen, leaked and unterminated keys: copies taken from hosts, backups, laptops or repositories, or left behind by leavers and retired automation. MITRE ATT&CK technique T1552.004 describes attackers searching ~/.ssh for private keys and brute-forcing passphrases offline. See the Leaked Credential Response Playbook.
• Backdoor keys: IR 7966 explains that adding one line to an authorized_keys file creates access that bypasses a privileged access management system, and that such keys can stay unnoticed for years.
• Pivoting: malware or an intruder uses keys found on one host to reach the next. IR 7966 warns that in dense estates an attack may spread to most servers after the first few.
• Over-privileged, shared and unintended use: keys authorised for root or able to run any command, one key shared by a team, or a file transfer key used to tunnel traffic past network controls.
• Host key exposure: a leaked host private key lets an attacker in the traffic path impersonate the server. The GitHub RSA SSH Host Key Exposure 2023 forced a global rotation and known_hosts updates for every client using the RSA key.
• Vulnerable implementation: SSH itself can be targeted. The XZ Utils Backdoor 2024 (CVE-2024-3094) could interfere with sshd authentication on some Linux builds before it was caught.

Discovery and clean-up

IR 7966 recommends an inventory and remediation project, and calls manual discovery across an enterprise "practically impossible", so automate it. Back up SSH configurations before each change.

1. Find SSH servers with existing vulnerability scanning, including network devices.
2. Collect authorised keys from every account, including non-standard paths set by AuthorizedKeysFile and keys served by AuthorizedKeysCommand. Record the account, host, key fingerprint and options such as from= and command=.
3. Find identity keys on servers, laptops, CI systems, images and repositories, and match them to authorised keys. Flag orphan authorised keys with no known identity key: IR 7966 treats them as possible backdoors.
4. Map trust relationships and flag those that cross environments (development to production), cross authorisation boundaries, reach root, or allow both incoming and outgoing key trust on one account.
5. Assign owners using a configuration database where possible. See the NHI Ownership Guide and the Service Account Inventory Template.
6. Lock down keys by moving authorised keys to root-owned locations that ordinary users cannot write, and point AuthorizedKeysFile there.
7. Monitor usage, then remove. IR 7966 suggests usually six to twelve months of log monitoring, including disaster recovery tests, before removing unused keys that nobody approves keeping.
8. Rotate what remains and replace keys that fail algorithm and length policy. External keys used with partners need coordinated, manual rotation.

Moving to SSH certificates

An OpenSSH certificate is a public key plus an identity, principals, options and a validity interval, signed by a CA key. Servers and clients then trust the CA rather than many individual keys. The ssh-keygen manual describes this as a different and much simpler format than the X.509 certificates used for TLS.

• Issue certificates after SSO and MFA with lifetimes measured in hours for people, and put the allowed principals in the certificate. The sshd_config manual says certificates without principals are not accepted through TrustedUserCAKeys.
• Always set a validity interval. The ssh-keygen manual states that by default certificates are valid from the Unix epoch to the distant future, which recreates the long-lived key problem.
• Use host certificates (HostCertificate on the server, @cert-authority in known_hosts) so clients can verify hosts without trust-on-first-use prompts.
• Protect the CA signing key. ssh-keygen can sign with a CA key held in a PKCS#11 token or an agent. See the Cryptographic Key Management Guide.
• Plan revocation. Publish a KRL with RevokedKeys, replace it atomically, and remember that the manual says an unreadable revocation file blocks public key authentication for all users.
• Keep an issuance record. IR 7966 (2015) cautioned that a host trusting a CA cannot show who may access it by inspecting the host alone, so log every certificate issued and its principals.

Short-lived certificates are a form of just-in-time access. See the JIT Access Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.

Brokered and privileged SSH

A broker gives users access to production without holding production keys, and closes the backdoor route IR 7966 describes if authorised keys are locked and monitored. IR 7966 also recommends reviewing key-based trust inside existing privileged access reviews.

• Route administrative SSH through a bastion or PAM gateway that authenticates the person with MFA and issues a short-lived certificate or injects a vaulted credential. See the Privileged Access Management Guide.
• Record privileged sessions and keep the key identifier or certificate ID with each recording. See the Privileged Session Management Guide.
• Use jump hosts, not agent forwarding. ProxyJump connects to the target through the jump host without exposing your agent there. Client ForwardAgent is off by default, while the server's AllowAgentForwarding defaults to yes.
• Consider removing inbound SSH where a cloud provider's session service authenticates with cloud identity and logs sessions centrally.

SSH keys for automation and NHIs

Automated access is where most keys live. IR 7966 recommends that requests for automated access name the allowed command, source hosts, business process and owner, and that automation keys carry command and source restrictions unless specially approved.

• One key per automation, never shared. Duplicated identity keys break accountability and are listed by IR 7966 for remediation; OWASP lists NHI reuse as NHI9:2025.
• Prefer short-lived certificates issued to a workload identity. See the Workload Identity Federation Guide.
• Scope Git access. For CI, prefer the platform's short-lived OIDC-based credentials and deploy keys limited to one repository. See the CI/CD Pipeline Identity Security Guide.
• Rotate on reassignment. IR 7966 says automation keys should be changed when an administrator who managed them is reassigned or leaves. See the Service Account Security Guide and the Secrets Management Guide.

AI agents and SSH

Agents that run shell commands can read the same home directories where SSH keys sit. MITRE ATT&CK records that in its "AI-Assisted Breach of Mexico's Government Infrastructure" campaign (C0064) the adversary tasked Claude Code to harvest credentials and SSH keys, and to establish persistence by injecting an SSH key into /root/.ssh/authorized_keys through a crontab script. Keep agents away from a person's ~/.ssh and agent socket, issue them their own short-lived, principal-scoped certificates, and alert on any authorised key change made from an agent's session. See the AI Coding Agents Security Guide.

Hardening basics

IR 7966 lists the policy areas: enable SSH only where needed, keep it current, disable unapproved authentication methods, limit SSH-accessible accounts including root, disable forwarding and use approved algorithms. Defaults below are from the current OpenSSH manuals.

• Retire weak keys. DSA is gone from OpenSSH 10.0; replace short RSA keys with Ed25519, and use FIDO-backed keys for administrators. See the Hardware Security Keys Guide.
• Patch quickly. In its 10.6 release notes (October 2026) OpenSSH said many security reports now come from AI-assisted research and that it will release more often. See the Linux Server Hardening Guide.
• Track key exchange. OpenSSH 10.0 made hybrid post-quantum mlkem768x25519-sha256 the default. See the Post-Quantum Readiness Guide.

Detection and monitoring

IR 7966 recommends comparing every configured authorised key against an approval record, alerting on any key without one, and analysing logs for unused keys and connections from unapproved sources.

ATT&CK notes that attackers can add keys through cloud interfaces, such as Google Cloud's metadata commands or an Azure API request, so monitor control planes as well as hosts. It also records Salt Typhoon adding authorised keys under root or other users on compromised network devices, which are often outside host-based monitoring. See Salt Typhoon Telecom Intrusions 2025. See the Linux Detection and Response Guide.

Framework mapping

An NHI Mgmt Group alignment checked against the framework texts. IR 7966 maps to SP 800-53 Rev. 4 and CSF 1.0; the identifiers below use current versions.

Common failure patterns

• Clean-up without lock-down. Keys are removed but users can still edit authorized_keys, so sprawl and backdoors return.
• Certificates that never expire. A CA is deployed but signing scripts omit a validity interval, so certificates inherit the "forever" default.
• A CA key on a file share. The signing key every server trusts is stored like an ordinary key.
• Bastion with a side door. A PAM gateway records sessions, but direct key logins still work, which is exactly the bypass IR 7966 describes.
• Removing keys too fast. Keys unused for a few weeks are deleted and a quarterly or disaster recovery job fails.
• Host key rotation with no verification path. When a host key must change, as in the GitHub RSA SSH Host Key Exposure 2023, users who cannot check the new fingerprint may accept an impostor's key. UpdateHostKeys and host certificates ease planned rotation.
• Automation keys with a shell. Backup or transfer keys without a forced command or source restriction give a thief full interactive access.

Metrics that show progress

See the Identity Security Metrics Guide.

Implementation roadmap

For lifecycle processes that cover keys alongside other NHIs, see the NHI Lifecycle Management Guide.

Practitioner checklist

• Inventory SSH servers, authorised keys and identity keys (including in code, images and backups), and map trust relationships.
• Assign an owner and an approval record to every authorised key; remove orphan keys after review.
• Move authorised keys to root-owned locations and monitor them against the approved baseline.
• Observe key usage for six to twelve months, then remove unused keys and rotate the rest.
• Disable password authentication and direct root login; retire DSA and short RSA keys.
• Issue short-lived user certificates after SSO and MFA, always with a validity interval and principals.
• Protect the CA signing key in hardware and publish a Key Revocation List.
• Broker and record privileged SSH, and use ProxyJump instead of agent forwarding.
• Apply restrict, command= and from= to every automation key; one key per automation.
• Give AI agents their own scoped certificates and keep personal keys and agent sockets out of their reach.

Standards and references

• NIST: IR 7966, Security of Interactive and Automated Access Management Using Secure Shell (SSH)
• OpenSSH: ssh-keygen(1) manual, certificates and key revocation lists
• OpenSSH: sshd_config(5) manual
• OpenSSH: sshd(8) manual, authorized_keys and known_hosts formats
• OpenSSH: ssh_config(5) manual
• OpenSSH: Release notes
• NIST: Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• OWASP: Non-Human Identities Top 10 2025
• MITRE ATT&CK: T1098.004 Account Manipulation: SSH Authorized Keys
• MITRE ATT&CK: T1552.004 Unsecured Credentials: Private Keys
• MITRE ATT&CK: T1563.001 Remote Service Session Hijacking: SSH Hijacking

Related NHI Mgmt Group resources: Privileged Access Management Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Secrets Management Guide · NHI Lifecycle Management Guide