Many teams end up sharing SSH private keys when onboarding new members. It’s often done for convenience — and sometimes urgency.
The issue is that shared keys make revocation and auditing messy. Multiple people effectively share the same identity, and rotating keys across many servers becomes painful.
Modern access models handle this differently by brokering SSH sessions based on individual identity rather than distributing private keys. Each session is scoped to a specific user and server, and access can be revoked centrally.
I wrote a breakdown focusing on the operational trade-offs rather than a product pitch:
The issue is that shared keys make revocation and auditing messy. Multiple people effectively share the same identity, and rotating keys across many servers becomes painful.
Modern access models handle this differently by brokering SSH sessions based on individual identity rather than distributing private keys. Each session is scoped to a specific user and server, and access can be revoked centrally.
I wrote a breakdown focusing on the operational trade-offs rather than a product pitch:
https://www.lynxtrac.com/ssh-access-without-sharing-private-keys
Curious how others here manage SSH access in growing teams.