SSH Key Management at Scale: Why Most Enterprises Get It Wrong

Ask most enterprise security teams how many SSH keys exist in their environment. Watch the discomfort. In most organisations of significant scale, the honest answer is: nobody knows.

SSH keys are the forgotten credential type in most privileged access programmes. Password management gets attention — password vault deployments, complexity policies, regular rotation schedules. But SSH keys fall through the gaps. They are created by individual engineers for individual purposes, distributed across servers, stored in home directories, and never inventoried or rotated. They have no built-in expiry. They leave no audit trail unless explicit logging is configured. And they often grant root-level access without requiring additional authentication.

Research into enterprise SSH key usage consistently reveals numbers that surprise security teams. A typical enterprise with 1,000 Linux/Unix systems will have somewhere between 10,000 and 50,000 authorised_keys entries across the estate. The majority of these keys have no documented owner, no documented purpose, and have never been rotated.

More concerning, mutual trust relationships created through SSH keys are almost never documented. When key A is authorised on server B, and key B is authorised on server C and D, and key C is authorised on servers E through Z, an attacker who gains access to the private key for key A has effectively gained lateral movement capability through a chain of trusted servers that the organisation has no map of.

SSH key proliferation happens for entirely understandable operational reasons. An engineer builds an automated script and creates a key for it. Years later, the engineer leaves, the script is forgotten, but the key remains. A penetration test generates test keys that are never removed. A deployment pipeline generates a new key for each environment and nobody decommissions old ones. A vendor is given temporary SSH access and never has their key removed when the engagement ends.

The absence of any built-in key lifecycle management in most Linux distributions means that without deliberate organisational process, keys simply accumulate. Unlike password accounts, there is no account lockout after inactivity, no password expiry forcing rotation, no central directory that reflects the current state of key authorisations.

A mature SSH key management programme has five components.

Discovery runs regularly across all systems to inventory every authorised_keys file and every private key in user home directories and application directories. This establishes a baseline of what exists and where.

Attribution maps each discovered key to an owner — a person, a system, or an automated process. Keys that cannot be attributed are candidates for removal after a grace period.

Lifecycle management establishes key rotation schedules and removes keys when their purpose is complete. Service account keys used by automated processes should be rotated on a schedule. Temporary access keys should be removed automatically at the end of the access window.

Central provisioning replaces the ad hoc creation of keys by individuals with a controlled provisioning process through the PAM platform. Engineers do not create their own SSH keys and distribute them manually — they request SSH access through the PAM platform, which generates short-lived certificates or managed keys, grants the specific access needed, and revokes them automatically.

Monitoring watches for unauthorised key additions, usage of keys that should have been rotated, and SSH connections that bypass the PAM platform's bastion host.

OmniPriv's SSH key management module addresses all five components, integrating key discovery and rotation with the broader privileged session management and audit capabilities of the platform.