Keybase SSH CA | Hacker News Reader

Keybase SSH CA

keybase.io

44 pointsddworken4 comments

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-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 && echo 'TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem' >> /etc/ssh/sshd_config && systemctl restart ssh-server`

Vault'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.

This was a summer internship project at Keybase, and the whole team is thrilled with how it turned out. The OP of this post is the author of the project and would be happy to answer questions here in HN.

One of the biggest devops pain points for a large team and large infrastructure is updating N servers every single time a team member is added or removed. Of course there are some other solutions to this problem, but the Keybase one is extra slick and just works automatically once it's set up.

It's also entirely powered by an open-source 3rd party bot, so it can be forked for improvement or to build something else triggered by cryptographic team membership changes.

We keep our pubkeys in sldapd... Since ldap is mainly read only, fairly easy to have many read only replicas for redundancy.

Reply on news.ycombinator.com