Vault SSH backend or "I don't get how this is secure"

[Jay Christopherson]

No doubt I have setup something incorrectly here.  But - I went through the documentation for setting up Vault and enabled the SSH backed.  I deployed the "vault-ssh-helper" to a few remote clients.  I installed Vault on my client laptop to test out the "automation" bits...

Then, I tested login and it works great.  A little too great in fact.  Like, I can login as anyone and as far as I can tell, the only bit of actual security is the CIDR range I setup in Vault when I setup the SSH backend.  Naturally, I allowed one of our corporate VLAN's that hosts developer workstations since these would be users that need SSH access to these hosts.  

But, there's nothing that prevents me from logging in as *ANY* account on the system.  Using a command like this:

$ vault ssh -role otp_key_role  <insert_user_here>@10.10.2.10

Heck, I can even login as root (I tested by setting PermitRootLogin to yes in sshd_config)!  If they are allowed to login to the host and the account is active, Vault will happily allow me to login.  So far as I can tell, I've done nothing to "authenticate" against Vault, other than my source IP falls within the CIDR range I set.

Is this by design?  For some reason, I was thinking that users would somehow be required to authenticate against the Vault for a token first - I went to the trouble to setup the Vault auth backend against LDAP (works).  But, it never asks for any sort of credential during the SSH backend process - it just logs me right in.

What am I missing here?  I like the portability of the OTP setup, but unless I have set it up very, very wrong, it seems extremely permissive to me.  All a potential attacker needs to do it squat on an allowed VLAN and have instant access to everything, right?

[Miguel Terrón]

What happens if you "rm .vault-token" in your home directory first Jay?

[Jeff Mitchell]

Hi Jay,

My guess is that you are not setting the "allowed_users" parameter on
the role. From https://www.vaultproject.io/docs/secrets/ssh/index.html:

"allowed_users optional for both types (String) If this option is not
specified, a client can request credentials to log into any valid user
at the remote host, including the admin user. If this field is set,
credentials can only be created for the values in this list and the
value of the default_user field."

Also, the connection to fetch the OTP and from the helper should be
TLS-encrypted, so sniffing on a VLAN shouldn't do much (although this
is a separate concern from acquiring credentials some other way and
using them to log in :-) )

Best,
Jeff

> --
> 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/67ff5e65-bb09-4a8b-a69a-e69a682261bf%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Miguel Terrón]

Ignore that, I missed the OTP part.

[Jay Christopherson]

Derp, both you and Miguel were correct - I *did* have a .vault-token because really early on going through the setup docs, I auth'd using my LDAP auth credentials.  

And yeah, I did not see the "allowed_users" parameter, so thanks for that reference!

[Jeff Mitchell]

It'd be a breaking change, but maybe the empty set of allowed_users should default to only the default user, instead requiring an explicit "*" to allow any.

I'll raise that proposal internally...

--Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/2814ea1c-4d71-4fbc-a3e5-b8d1a50bea08%40googlegroups.com.

[Ryan King]

I, for one, would be surprised that leaving and empty list would lead to allowing all users.

-ryan

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GFG4ZTBS9yf6hcmb-AY%2BsZePZSnc4zC3Swzy0QvE-cRcw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Director of Engineering at Bolt Financial, Inc.

https://bolt.com/

r...@bolt.me

[Miguel Terrón]

The intuitive behaviour of something called an "allow list" should be to allow nothing when the list is empty.

[Vishal Nayak]

Hi,

An issue has been raised to track this.

https://github.com/hashicorp/vault/issues/1116

As Jeff proposed, it is safer to make an empty allowed_users list to only succeed in creating credentials for the default_user. An explicit "*" on allowed_users should be required to allow logins to all usernames at the remote host.

Thanks and Regards,

Vishal

[Jay Christopherson]

Awesome.  The allowed_users field is working correctly for me, but I agree with the other comments that it makes more sense to require an explicit "*".

[Jeff Mitchell]

We'll definitely change this, but I do want to note that, although we
are all in agreement with the fact that the default behavior should
change, it is at least *documented* default behavior :-D

--Jeff

> https://groups.google.com/d/msgid/vault-tool/0e9ee08b-274a-46e7-9464-86ba733b7da4%40googlegroups.com.