[Bender]

LDAP ad AD are the ways I have seen SSH key management done. [1] LDAP clients should be configured to cache creds in SSSD.

Servers and workstations (clients of the LDAP server) should be configured to only use authorized keys from LDAP and not locally as they can contain multiple public keys which quickly gets harder to audit and harder to catch someone slipping a public key into the local authorized_keys.

[1] - https://serverfault.com/questions/653792/ssh-key-authenticat...

[brintha]

That’s a good point. LDAP/AD-backed SSH key management is a solid approach, especially in environments that already have directory infrastructure in place.

Centralizing authorized keys and avoiding local authorized_keys sprawl definitely improves auditability.

The scenarios I was thinking about in the post were more around smaller cloud-native teams that don’t run LDAP/AD at all, or where servers are fairly ephemeral and identity is managed elsewhere.

In those setups, distributing and rotating SSH keys — even via automation — can still become operationally noisy.

I agree that directory-backed key management is a strong pattern when that infrastructure already exists.

[Bender]

For cloud managed environments there must be a configuration management or configuration deployment mechanism already in place for distributing secrets or one would hope and that should be the tool to deploy keys. Tracking both private and public keys to me would suggest they belong in a secret management tool ideally backed by an HSM somewhere. Each public and private key should be mapped to an identity both are equally important since anyone can shove their public key into the authorized_keys file or directory. My preference is to save all of those under /etc/ssh/keys/ and preserve ownership to the owner or service owner and ensure that if someone manually adds a public key into /etc/ssh/keys/username that it triggers a security alert and clobbers it with what is supposed to be there per some git configuration. This will require re-training or unlearning bad habits on the part of the team members and this should be reviewed, approved and communicated by the CSO so that people know what is expected for service and human trust relationships in the cloud in my opinion.

sshd_config would need to be updated with:

    AuthorizedKeysFile  /etc/ssh/keys/%u

so that keys under home directories are ignored. Each username or service account name in /etc/ssh/keys can have multiple public keys but each of those keys must be mapped in a security management repo or security management tool. If anything is manually added the secrets management tool should get a diff then restore only the public keys that are in the secrets management tool.

[brintha]

That’s a very solid pattern. Using config management + secrets tooling + drift enforcement is definitely the mature way to handle SSH keys in cloud environments.

I agree that mapping both public and private keys to identity and enforcing something like /etc/ssh/keys/%u with config-backed reconciliation closes a lot of gaps — especially when you have strong policy ownership and review processes in place.

In our case, we’ve been approaching it from a slightly different angle: avoiding distribution of private key material to end-user machines altogether. Private keys and passphrases are stored under AWS KMS–backed encryption, and access is mediated per session rather than copied around.

The goal isn’t to replace good secrets management — it’s to reduce proliferation of key material while still keeping identity mapping and auditability intact.

I think in teams that already have disciplined config management and drift detection, what you described works well. The friction tends to show up more in smaller or fast-moving environments where those controls aren’t consistently enforced.