SSH OTP with Multiple Users

[Byron Kim]

I'm implementing Vault and want to implement the SSH backend.  We are currently putting this in place due to compliancy and one of the main takeaways is being able to audit a users access to a remote host.  While vault audits who logins to a particular server, it won't log what actions happen on the server (nor would I expect it to).  I was looking at using Vault to handle the SSH access for multiple users on a remote host.  My question is:

Is there an "easy" way to handle multiple users on a single host?  Would I need to create a role for each user and then have a policy for each user?

Example:

ServerA: userA, userB < each with their own permissions

Vault-Server:

  - create an OTP role for userA

  - create an OTP role for userB

Policy for userA

path "ssh/creds/otp_key_role_userA" {
  policy = "write"
}

Policy for userB

path "ssh/creds/otp_key_role_userB" {
  policy = "write"
}

This seems a bit cumbersome as you have a large # of users.

[Vishal Nayak]

Hi Byron,

Multiple users on a single host (or for all the hosts in the subnet
specified by cidr_list on the role) are allowed to login if the user
names are listed on the role through `allowed_users` field, but the
policies for all the users will be the same as the ones that are on
the role. Each set of policies would require a role. Its not possible
to have a single role to issue tokens with different policies.

If you are set up with OTP method of authentication, great. If you are
not, and if you happen to use OS distributions where OTP method is not
supported, then you might want to take a look at the new SSH CA auth
variant in the backend. Its already included in the beta release and
will be officially out in the soon to be released v0.7.0. This type
will not audit the logins on the host machines. But it does audit the
certificate signing. By setting a low TTL on the certificates issued,
this can also be a very elegant way to set up the SSH infrastructure.

https://github.com/hashicorp/vault/blob/master/website/source/docs/secrets/ssh/index.html.md#iii-ca-key-type

Best,
Vishal

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/d60c8bfd-95a0-4a4f-97a9-fa4b6f2ade3b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
vn

[Byron Kim]

Hi Vishal,

Thanks for the reply!  In regards to your first comment, wouldn't UserA be able to impersonate as UserB if both UserA and UserB are in the `allowed_users` (assuming they both had access to the policy)? 

I know Vault would audit the authorization, but that is not desirable.

We are currently being audited for compliance and need to be able to segment SSH access via environments with each user having a unique login on each system for auditing purposes.  OTP would be the preferred method, but it sounds like it would be messy where I would have to dynamically generate a role for each cluster of servers per user per environment.  Does that sound right?

[Vishal Nayak]

Hi Byron,

That seems about right. As of now, there is no alternative than doing
what you just said. Sorry.

Regards,
Vishal

> https://groups.google.com/d/msgid/vault-tool/f6eb5a54-2eae-41f8-b893-19f2b72a568c%40googlegroups.com.