[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.