5 ms·

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 ea

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 9y ago
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-secure-access-with-ssh/ https://code.facebook.com/posts/365787980419535/scalable-and...
- jen20 9y ago
  As a follow up - I would now also take a _very_ serious look at Teleport [1] for managing SSH. [1]: https://gravitational.com/teleport/ https://gravitational.com/teleport/
- fragmede 9y ago
  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 9y ago
    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 9y ago
      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.
- markpeek 9y ago
  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 https://github.com/cloudtools/ssh-cert-authority
- mi100hael 9y ago
  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.
- true_tuna 9y ago
  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 9y ago
    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).

jen20 9y ago

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-secure-access-with-ssh/ https://code.facebook.com/posts/365787980419535/scalable-and...

jen20 9y ago
As a follow up - I would now also take a _very_ serious look at Teleport [1] for managing SSH. [1]: https://gravitational.com/teleport/ https://gravitational.com/teleport/
fragmede 9y ago
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 9y ago
  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 9y ago
    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.
markpeek 9y ago
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 https://github.com/cloudtools/ssh-cert-authority
mi100hael 9y ago
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.
true_tuna 9y ago
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 9y ago
  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).