Vault: Feature request: Vault as SSH certificate authority

[mdub]

OpenSSH supports signing of keys by a certificate authority, much like TLS:

• https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

I'm aware of several projects that are able to issue short-term, signed SSH keys. Netflix's BLESS is the most recent:

• https://github.com/Netflix/bless
• https://github.com/realestate-com-au/sshephalopod
• https://github.com/cloudtools/ssh-cert-authority

Could Vault's SSH secret backend issue CA-signed SSH keys in the same way?

[jefferai]

This is something we've had our eye on for a while. Unfortunately we can't reuse much of the code that we have because the OpenSSH format is custom rather than using standard X509 certificates. I hadn't seen the cloudtools repo before, though; it's possible we can reuse a bunch of the code from cloudtools as it's in Go and already knows how to serialize/deserialize.

Another question then becomes whether it's a better idea to do this within the SSH backend or the PKI backend.

@vishalnayak for your radar...

[mvdkleijn]

@jefferai This would be a very nice feature indeed. I believe the SSH backend is already _nearly_ there.

Specifically, the Dynamic Key Type entry in the docs talks about SSH keys being generated on the fly for a user that wants to access a machine, then uploads the public key to the machine's authorized_keys file.

The scenario I imagine:

1. Vault admin uploads SSH CA keys & tells servers to trust the CA keys
2. User registers / uploads their personal, public SSH key to the vault
3. User requests vault to sign their key with the CA keys
4. User logs into the server with their signed key

The vault doesn't need to upload public keys to server's authorized_keys file (messy), Vault admins retain full control over the CA keys and which users are allowed to be signed and users retain their own SSH keys.

[matya]

This is highly appreciated, and would allow to use it for usecases like this one:
https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/

[derek-virtustream]

I have a use case where we would like to assert trust of both host keys and client keys for cloud infrastructure rollout via automation, and the CA method makes this a _lot_ nicer. Would love to see this feature.

[elyscape]

Another benefit to using SSH CA certificates is that sshd will log the certificate ID and serial when a connection attempt is made. By configuring the syslog daemon on a system to forward those messages to Vault, it should be possible to get the level of auditing provided by the current One-Time-Password SSH backend. In fact, that should make it possible to get that auditing into the current Dynamic Key SSH backend.

[elyscape]

For example, something like the following should make rsyslog v5+ forward the relevant messages to a Vault UDP syslog listener:

# The following line may not be necessary
$ModLoad omfwd
if $syslogtag == 'sshd' and $msg startswith 'Accepted publickey' then @127.0.0.1:VAULT_AUDIT_PORT

And the following should work for rsyslog v7+:

if $syslogtag == 'sshd' and $msg startswith 'Accepted publickey' then action(
    type="omfwd"
    Target="127.0.0.1"
    Port="VAULT_AUDIT_PORT"
    Protocol="udp"
)

[jefferai]

This has been merged into 0.7 beta.