Tokens issued via vault-ssh-helper OTP are not being revoked properly

[jrdemasi]

Currently, I am using SSH OTP to login to some CentOS 7 systems and everything is working as intended (or, at least, as I want them to :-)). However, when I logout, I get output like the following, and tokens are not actually being revoked:

[<sshuser>@hostname ~]$ exit
logout
Connection to xxx.xxx.xx.xx closed.
failed to revoke key: Error making API request.

URL: PUT https://mydomain.tld/v1/sys/leases/revoke/ssh/creds/<sshuser>/ArYTGUV78708q14rXXmNNrZg
Code: 403. Errors:

* 1 error occurred:
	* permission denied

If I manually add a policy to grant access to sys/leases/revoke/ssh/creds/* and apply it to my users, it works fine, but of course they can also revoke any tokens in the path then. Shouldn't this be using auth/token/revoke-self? Is there something I'm missing about the appropriate way to be using this?

Thanks in advance!

[aram535]

I also just ran across this. I rather not add revoke to all users.

[jrdemasi]

Yeah, I'm not convinced this is maintained or cared about. I've since just written my own functionality to avoid using their ssh helper. :-/

…

On Mon, Oct 28, 2019, 04:30 aram535 ***@***.***> wrote: I also just ran across this. I rather not add revoke to all users. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#40?email_source=notifications&email_token=AENJAJ3XEVPITGMB3RQBVLTQQ25M7A5CNFSM4HGXQMJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECMNACA#issuecomment-546885640>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AENJAJ3D26J7EMUEF3U2EHDQQ25M7ANCNFSM4HGXQMJQ> .

[ncabatoff]

The code that does the revoke actually lives in the vault ssh command, not the helper.

revoke-self isn't the right solution, because that would revoke the token the user used to authenticate to vault, but we just want to revoke the lease that was created for the SSH credentials.

I'm not very familiar with the SSH OTP functionality, but I had a look at when the code in question was introduced, and I saw in an earlier version that it had this comment above it:

	// If the session established was longer than the lease expiry, the secret
	// might have been revoked already. If not, then revoke it. Since the key
	// file is deleted and since user doesn't know the credential anymore, there
	// is not point in Vault maintaining this secret anymore. Every time the command
	// is run, a fresh credential is generated anyways.

This suggests to me that the error message is annoying but could be ignored without risk.

[jefferai]

I don't think that's quite the same situation but @ncabatoff is right in that you probably don't want to revoke the token that generated the lease as then every time you SSHed somewhere you'd have to reauthenticate to Vault.

Given that lease IDs are not public and you'd have to know the exact lease ID to revoke it, most people simply grant access to sys/leases/revoke. Although it does look like we should update the bit in the SSH secrets engine to use the body form of the revoke call instead of the path form.