Better SSH Authentication with Keybase

The most common way of handling SSH authentication is public key authentication. This is much stronger than simply using a password, but it creates the problem of how to securely manage changes to SSH keys over time. If ten new people join a company and five others leave, someone has to add the ten new keys to each server and remove the previous five. This is a process ripe for automation. Some companies do it by centralizing storage of SSH public keys and baking them into images as applications are deployed. But SSH supports another way of handling authentication: Certificate Authorities (CAs).

With an SSH CA model, you start by generating a single SSH key called the CA key. The public key is placed on each server and the server is configured to trust any key signed by the CA key. This CA key is then used to sign user keys with an expiration window. This means that signed user keys can only be used for a finite, preferably short, period of time before a new signature is needed. This transforms the key management problem into a user management problem: How do we ensure that only certain people are able to provision new signed SSH keys?

Keybase SSH CA

Enter Keybase. Keybase Teams allow us to easily define secure auditable groups of Keybase users. And each Keybase user is defined by a strong cryptographic identity. Keybase Chat provides end to end encrypted and authenticated messaging on top of Keybase Teams. This is a powerful primitive that can be used for building secure, encrypted workflows. We recently open-sourced chatbot libraries for Go, Python, and TypeScript that make all of this a lot more accessible. We’ve developed and open-sourced a chatbot for managing SSH keys on top of Keybase.





With our SSH CA chatbot, you can define subteams for managing access to different resources. For example, internally we have two that we use to control SSH access, keybase.ssh.production and keybase.ssh.staging .

Granting a new employee access is as easy as adding them to the relevant Keybase team. And even better, revoking access is just a matter of removing someone from a team. All of this is backed by Keybase's identity system and built on top of Keybase as a chatbot. There are two components to this system.

keybaseca is the server side of the chatbot that receives signature requests via Keybase chat. keybaseca will only sign an SSH key if it comes from someone in the configured teams. It also keeps detailed audit logs on signed keys including information about what device provisioned a given key.

is the server side of the chatbot that receives signature requests via Keybase chat. will only sign an SSH key if it comes from someone in the configured teams. It also keeps detailed audit logs on signed keys including information about what device provisioned a given key. kssh is a wrapper around ssh , and is the client side of the chatbot, sending signature requests via Keybase chat. As a user of the CA bot, you don't have to think about creating new keys, key expiration, or identity. You just run kssh user@server instead of ssh user@server and keys are automatically provisioned in the background.

This removes the need to manage SSH keys manually, and we think it increases security for most teams. See the Getting Started directions on Github for information about setting up and deploying the Keybase SSH CA bot. It's easy to get up and running, so there's no reason not to give it a try. I even use it for managing SSH access to my personal servers!

Keybase ChatOps

We’re really excited about the potential for ChatOps flows built on top of Keybase, so we’d love to see what else people create! A few ideas we’ve thought of: password management, TOTP sharing, AWS IAM credential sharing, and CI/CD integrations.

— David Dworken

https://keybase.io/dworken