SSH auth via Vault with AD creds


I was wondering if there is a way of SSH authentication on a device using AD creds using Vault.


Please give more details - this is sufficiently loosely defined that the answer could be “yes” or “no” depending on how it is interpreted.

Well, i have some routers which will be accesed via ssh by some of the users of the AD domain, the main thing is getting authenticated via ssh on these routers by a token provided to the user via vault or something similar (vault is not familiar to me), so it wont be needed to manage lot of ssh creds, and also if an AD user gets removed, that user wont be able to connect again via ssh.

I hope this explanation will help you understanding a bit more, any questions feel free to ask me for more details.

Thanks for your answer.

One option could be to have the users log in to Vault using their AD username/password, and to grant these users access to a Vault SSH secrets engine, configured to sign their SSH key, providing an SSH certificate to allow access.

However, there are quite a lot of potential challenges down this path:

  • The SSH server on the routers would need to support trusting an SSH CA. Even though this is a standard feature that has been part of OpenSSH for many years, you’d be at the mercy of whether your router OS image uses a suitable SSH server, and whether it exposes configuring this feature. This is definitely the first thing to check.

  • When you come to learning how to configure Vault, bear in mind that the one SSH secrets engine supports multiple modes of operation - and so you may see options in some of the APIs that are not relevant to you. The signed certificates a.k.a. CA mode of operation is the only one that is suitable here, since it’s the only mode that is potentially compatible with routers where you can’t freely modify the installed OS.

  • If you do get this set up, you may find that you can allow or deny access acceptably, but enforcing different levels of access on different users may be complicated. You may find yourself needing to choose between still needing to create local user accounts on the routers in order to assign fine-grained permissions.

  • Related to this, you’ll likely also have to decide how important it is to be able to associate router logins with particular users in audit logs - one way to solve the previous point is to allow Alice, Bob and Charlie to obtain short-lived credentials to connect to the routers as a shared ‘admin’ account … but now your router logs don’t identify which employee was the one actually performing the actions! You may be able to correlate activity with Vault logs to see who requested credentials around that time, but it’s extra complexity.

  • Lastly, don’t underestimate the user education burden of such a solution. Individual users, even ones very familiar with SSH, are often not familiar with SSH certificate signing. Expect a need to educate, and potentially create a small internal wrapper script that glues together the “get a certificate and login” operations with values defaulted appropriately for your environment.

In summary, there is a possibility here, but don’t underestimate the complexity of designing a deployment of this solution.

Thanks!, It really helpd :slightly_smiling_face: