Treat every SSH user key as a persistent access grant

Copying a public key into an authorized-keys file creates an access grant that can outlive the person, project, or automation that justified it. SSH keys need the same ownership, approval, review, and termination discipline as other privileged identities.

Source fact:

NIST Interagency Report 7966 addresses enterprise management of interactive and automated access using Secure Shell. It focuses on SSH user-key provisioning, termination, and monitoring, including the risks created when keys grant high privileges or support unattended automation. The publication treats key management as an enterprise access-control problem rather than solely a cryptographic file-format issue.

SSH public-key authentication can remove password use from a connection while leaving authorization decisions in distributed server files and device configurations. Automated keys may connect systems with broad privileges and no person present at each use. Effective control therefore depends on knowing which key is accepted where, who or what owns it, what restrictions apply, and how the grant is removed.

Boundary

The 2015 NIST report should be applied with current product and cryptographic guidance. It does not make every SSH key inappropriate, prescribe one management product, or establish that a discovered key is malicious. Host keys, user keys, certificates, agent forwarding, and secrets embedded in scripts present different risks. Removing an unidentified automation key without dependency analysis can cause an outage.

Applicability questions

• Where can administrators, vendors, applications, and file-transfer jobs install authorized keys?
• Can each accepted key be linked to a current human or workload owner and approved purpose?
• Which grants provide root, enable, command-shell, or cross-environment access?
• Are source, command, forwarding, or time restrictions available and used appropriately?
• How quickly can an incident responder revoke one key across all targets?

DSE recommendation:

Discover authorized keys using supported host, device, configuration-management, and identity tooling. Normalize fingerprints rather than copying private material. Build a grant record for each key-to-account-to-target relationship, including owner, business process, privilege, source, creation evidence, last observed use, review date, and revocation method. Investigate orphaned keys before removal and isolate high-risk unknowns through change control.

Move routine access toward centrally governed provisioning or short-lived SSH certificates where product support and risk justify it. For retained static keys, use unique keys per trust purpose, protect private keys, restrict authorized-key options where supported, and monitor use. Tie employee and vendor termination to a tested SSH revocation step. Give automation owners a rotation and recovery procedure that avoids sharing one key across unrelated systems.

Verification and evidence

Keep fingerprint inventories, target-account mappings, approvals, owner attestations, use telemetry, exception records, and revocation test results. Sample a terminated or test identity and prove that access is denied on every recorded target while required jobs continue with replacement credentials. Reconcile the inventory with configuration changes and newly observed fingerprints on a defined schedule.

Official references

• NIST IR 7966