[serkanh]

So let say you have bunch of servers that your team has to access via ssh, how would vault help adding users public keys add it to ~/.ssh/authorized_keys of each machine? i am familiar with vault locking/unlocking secrets but not sure if Vault can help centralizing and deploying those keys to individual machines.

[jen20]

A good solution to this problem is to use an SSH Certificate Authority - then you need only configure the CA certificate on each box, and you can either issue semi-long-lived certificates to each user who needs access, or use something like Vault to issue short-lived certificates intended for one-time use.

This model is described in an excellent post by Facebook from a while back [1].

(Disclaimer: I used to work at HashiCorp, and put this model into production there, though the Vault support for issuing short-lived certificates was added after I left)

[1]: https://code.facebook.com/posts/365787980419535/scalable-and...

[fragmede]

Using an SSH Certificate Authority is also my recommendation, but be aware that it's relatively new, so associated tooling with it is not super mature yet. In particular, the user still needs some bits in order to login, and whether they generate it themselves and send it off to get signed, or the bits are generated for them on the backend and the user simply needs to receive them, there's a management aspect to it that isn't a totally solved problem with open source tools.

It's not a difficult problem, mind you, but there was custom code written that runs on developer laptops (OS X and Ubuntu) to support this workflow.

(Despite being a very similar looking string of bytes as more traditional pub/private keys, it's different in the SSH-Agent protocol, so don't assume all ssh-agent-looking daemons support it.)

[bsabrin]

ScaleFT uses a certificate based approach and issues short lived certain for SSH and RDP. Also has a policy engine to set additional access controls.

[true_tuna]

I tried to deploy them to grant developers limited time access to the hosts running their services. Didn't really work out and I killed the project.

[mi100hael]

One other handy feature that we're using is the ability for Vault to set user IDs in the signed key ID field which then get logged by sshd on the remote host. That way we can still audit who exactly logged in if using a single user on the remote host.

[markpeek]

Agreed on an SSH Certificate Authority being a good solution. Another open source project (disclaimer: I'm affiliated with it) which provides approval controls is available here: https://github.com/cloudtools/ssh-cert-authority

[jen20]

As a follow up - I would now also take a _very_ serious look at Teleport [1] for managing SSH.

[1]: https://gravitational.com/teleport/

[true_tuna]

You have to build a new ssh CA for each class of server. There's no mechanism for granting access by host name. This becomes unmanageable fast.

[blue6249]

You can represent that pretty easily with principals. Just make sure that each host has itself listed as a principal and generate keys that contain that same string. It's pretty common to have a set of increasingly general principals (I.e. Hostname, cluster, tier, root@everywhere).