Vault: SSH as Auth Backend

Created on 13 May 2015 · 15Comments · Source: hashicorp/vault

_SSH accounts as secret backends #115_ focuses on generating ssh accessible user accounts from secrets stored in vault.

The SSH Auth backend however would allow to authenticate to vault by SSH connecting to a vault server with a trusted SSH key.
If understand correctly it would work analog to the cert Auth Backend.

The SSH Auth backend might be named ssh. An operator would configure it with trusted SSH public keys. These keys could be either user keys or host keys.

For example one could have a pool of cloud instances for which the SSH host keys were generated during cloud-init. After verifying these keys they would be used to configure auth/ssl also similar to the cert auth backend:

vault write auth/ssh/i-0e48fbcf display_name=i-0e48fbcf \
   policies=web,prod \
   key=@i-0e48fbcf_rsa_key.pub

To login from a cloud host:

sudo vault auth -method=ssh -key=@/etc/ssh/ssh_host_rsa_key

The sudo might be needed for accessing the private key /etc/ssh/ssh_host_rsa_key. The command would:

Determine SSH server address associated with vault. With a vault address VAULT_ADDR='https://vault.example.com:8200' this might be under vault.example.com:8222
The command above would essentially copy the login response by SSH connecting an copying file login :

sudo scp -i /etc/ssh/ssh_host_rsa_key -P 8222 vault.example.com:login

The output would look similar to other methods (adapted from userpass method):

{
  "lease_id":"",
  "renewable":false,
  "lease_duration":0,
  "data":null,
  "auth":{
    "client_token":"c4f280f6-fdb2-18eb-89d3-589e2e834cdb",
    "policies":[
      "root"
    ],
    "metadata":{
      "username":"i-0e48fbcf"
    },
    "lease_duration":0,
    "renewable":false
  }
}

.3. The auth cli would capture the client_token and use this in subsequent CLI commands and would take care of the normal things such as to lease renewals.

Blog post Writing a replacement to OpenSSH using Go (2/2) appears to suggest that this kind of capability could be implemented using golang.org/x/crypto/ssh.

Unfortunately I don't have any code up my sleeves for this nor can I commit to contribute this.

However I am curious whether such a capability would be desirable and fit into the vault architecture. In particular the idea to have vault listen at another address for ssh connections.

Source

henrjk

👍8

Most helpful comment

Oh hey, I was just thinking this would be a fantastic feature and I searched the history for it. It sounds like it might be complicated by the need to proxy thru a TLS connection. But is there any chance it could be implemented as a new listener so it could be called with an SSH client? This would allow, for example, user authentication via a forwarded ssh-agent. I'm thinking of a workflow like:

user@workstation$ ssh-add .ssh/id_rsa
Password: ...
Identity added: .ssh/id_rsa

user@workstation$ ssh -A bastion-host

user@bastion-host$ export VAULT_TOKEN=$( ssh [email protected] )

user@bastion-host$ echo $VAULT_TOKEN
82c1cd4c-3c15-415f-991f-93a169d2e3a8

user@bastion-host$ vault token-lookup
Key             Value
---             -----
accessor        6f73e74f-ec3f-4189-bae3-ac0a032924db
creation_time [... etc ...]

This would be incredibly useful and make life a lot easier for our users. I realize it would introduce a lot more complications to implement another listener... It could be implemented as a separate service on top of Vault of course.

daveadams on 23 Oct 2016

👍2

All 15 comments

@henrjk This is a great idea! We looked at supporting this for 0.1, but its a fair bit more involved than the cert backend. The TLS handshake is broadly implemented, and luckily we can just overload our use of TLS for that. However for Vault, we would need to do the SSH handshake over TLS, which is not impossible, just tricky.

Basically, the handshake would need to be a less "interactive" as Vault is request/response oriented, without compromising the security. This can probably be done by sending the current timestamp in plaintext, as well as signed with the SSH key. The server can verify the signature is valid and done by a trusted cert, as well as ensuring the freshness of the timestamp to avoid a replay attack. It's not quite as good as the interactive random nonce approach of SSH, but may work well enough.

armon on 14 May 2015

+1 for an SSH auth backend

albertca on 1 Dec 2015

2016-04-20 0:27 GMT+02:00 Jack Pearkes [email protected]:

Closed #193 https://github.com/hashicorp/vault/issues/193.

Does this mean it is no longer a desired feature? Or has this already been
commited?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/hashicorp/vault/issues/193#event-633695774

Albert Cervera i Areny
http://www.NaN-tic.com
Tel. 93 553 18 03

albertca on 20 Apr 2016

@albertca

Some of the Vault issues were closed by mistake from a syncing software. We apologize for the confusion caused. We have reopened the issues that were closed and are investigating the problem that caused this. We are very sorry for the inconvenience.

vishalnayak on 20 Apr 2016

user@workstation$ ssh-add .ssh/id_rsa
Password: ...
Identity added: .ssh/id_rsa

user@workstation$ ssh -A bastion-host

user@bastion-host$ export VAULT_TOKEN=$( ssh [email protected] )

user@bastion-host$ echo $VAULT_TOKEN
82c1cd4c-3c15-415f-991f-93a169d2e3a8

user@bastion-host$ vault token-lookup
Key             Value
---             -----
accessor        6f73e74f-ec3f-4189-bae3-ac0a032924db
creation_time [... etc ...]

daveadams on 23 Oct 2016

👍2

To expand on what daveadams said, this kind of workflow would also allow for the use of smartcards for authentication. Unless I'm missing something, the easiest way to gain access to a Vault instance is to steal someone's token - but I (and hopefully a lot of other people) protect my SSH key better than I could ever protect an arbitrary, rotating token. Thus it would not just be more convenient, but far more secure.