3 ms·
For those interested in this approach, but who would prefer fewer moving parts on the actual machines, I have had great experiences with Vault's signed SSH CA s
by mdaniel 7y ago
For those interested in this approach, but who would prefer fewer moving parts on the actual machines, I have had great experiences with Vault's signed SSH CA support, which includes the ability to get very short leases assigned to specific user accounts: https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates.html#signing-key-amp-role-configuration https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert...
It's possible the Keybase CA bot solves other problems, but as far as "quick to get started," one cannot beat `curl -sSfo /etc/ssh/trusted-user-ca-keys.pem https://my-vault:8200/v1/ssh-client-signer/public_key https://my-vault:8200/v1/ssh-client-signer/public_key && echo 'TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem' >> /etc/ssh/sshd_config && systemctl restart ssh-server`
- ddworken 7y agoVault's SSH certificate signing support is definitely really great and is something I modeled this project after while developing. Though I see it as more of a building block as opposed to a complete solution. With this project you: * Don't have to run Vault (for companies that don't already use Vault, setting it up is a significant commitment). * Get simple user/group management within Keybase. * Get a simple CLI tool, kssh, that can be used instead of ssh that automatically manages renewing certificates. With vault a user has to manually use curl to request a new certificate whenever their's expires. With kssh, you just run `kssh user@server` and it all automatically works. It is also worth noting that the example you posted above does not handle multiple realms of servers where some people only have access to staging and not production. With our SSH CA, this is all included in the default setup.