Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: ssh certificate revocation list #3377

Closed
OferE opened this issue Sep 26, 2017 · 27 comments
Closed

feature request: ssh certificate revocation list #3377

OferE opened this issue Sep 26, 2017 · 27 comments

Comments

@OferE
Copy link

@OferE OferE commented Sep 26, 2017

Feature Request:
Please add support for generating revocation list for SSH certificates.
Currently I need to manually keep track of all the certificates I signed using vault and generate a revocation list manually. Would be great if this can be supported by vault itself.
Thanks!

@jefferai
Copy link
Member

@jefferai jefferai commented Sep 26, 2017

We generally recommend making certificate lifetimes useful for only a single connection. As a result CRLs are unnecessary. This workflow can be made easier using vault ssh.

@OferE
Copy link
Author

@OferE OferE commented Sep 26, 2017

This is too strict for development accounts. The bureaucracy of creating new certificate every time is too much.
(BTW I opended a ticket in terraform for not supporting connections with certificates).

For production accounts it's reasonable.

@jefferai
Copy link
Member

@jefferai jefferai commented Sep 26, 2017

Isn't it the same workflow?

@OferE
Copy link
Author

@OferE OferE commented Sep 27, 2017

I'm not sure what do you mean by workflow.
We use ssh certifictaes to grant permissions to real human users not for automation/services.

Our product is in development mode and still not in production.
For development clusters I prefer to work with long living certificates. For production we will issue short living certificates.

@jefferai
Copy link
Member

@jefferai jefferai commented Nov 30, 2017

What I mean is, if you use vault ssh to connect (or a custom script that does essentially the same thing), whether the certificates are short lived or long lived makes very little difference.

@johndistasio
Copy link

@johndistasio johndistasio commented Dec 28, 2017

That workflow is predicated on the Vault cluster being available and reachable for vault ssh, no? If I'm using certificates for SSH, there is probably a good chance I'm doing it to avoid a dependency on some separate authentication infrastructure during an emergency.

It would be nice to distribute a CRL with Consul Template or similar.

+1 for this feature request.

@kogent
Copy link

@kogent kogent commented Mar 1, 2018

I would agree that there are some use cases where longer ttls is appropriate. Being able to revoke those would be very welcome.

Also not every tool is able to leverage vault ssh.

@kenrestivo-stem
Copy link

@kenrestivo-stem kenrestivo-stem commented Mar 12, 2018

We have a use case where we need:

  1. Long-lived connections and client SSH keys
  2. Only SSH protocol/port is available from the client; there is no connection to Vault
  3. Ability to revoke keys on a key-by-key basis

I don't see a way to do this with Vault CA (which isn't really a CA as there's no CRL and the host doesn't check) or OTP (which requires that the client be able to reach Vault in order to fetch its OTP, nor do I see a way to revoke its access on a client-by-client basis either)

@tq05
Copy link

@tq05 tq05 commented Jul 29, 2018

Any update on this.
Seems like quite a fundamental functionality to have if you start supporting ssh ca and play in this world as well.

Makes a hard sell against other technologies otherwise

@nafpliot
Copy link

@nafpliot nafpliot commented Aug 6, 2018

I also find this a really nice to have feature. If revocation cannot be done, we should at least have a way to list all the certificates that are signed. It's easy to lose track if you work with long living certificates...

@adambaumeister
Copy link

@adambaumeister adambaumeister commented Aug 7, 2018

+1. The idea of short-lived certificates makes good sense but pkey auth is widely used for many other applications where it's not applicable.

Revocation or at least an index of signed certificates would be a great feature to be built into the workflow.

@jefferai
Copy link
Member

@jefferai jefferai commented Aug 8, 2018

The idea of short-lived certificates makes good sense but pkey auth is widely used for many other applications where it's not applicable.

Can you give us examples of these applications/use-cases? It seems like you're better off in the end making some wrapping around those to use short-lived certificates than using long-lived ones.

Storing lists of issued certificates in Vault is relatively expensive, especially when they're very short term, causing a lot of storage churn. I should note however that you don't need Vault specifically to generate a KRL for you. KRLs are unsigned (AFAICT) so anyone can generate one at any time.

@adambaumeister
Copy link

@adambaumeister adambaumeister commented Aug 8, 2018

@jefferai

Can be summarized as any case where:

  • The vault server is not reachable from the client
  • Wrapper code or binaries are undesirable

A practical example would be the classic (and ubiquitous) SSH proxy server, another would be standalone cloud deployments where the password vault is on-prem.

It's a chicken and egg thing with the KRL as well, without any storage on the Vault side I don't have the pkeys to build the list.

A simple solution might be an option somewhere to not hash the pkey when sent to the audit plugin.

@jefferai
Copy link
Member

@jefferai jefferai commented Aug 9, 2018

@jefferai
Copy link
Member

@jefferai jefferai commented Aug 9, 2018

Although I'd opt out of hashing the serial number rather than the private key.

@adambaumeister
Copy link

@adambaumeister adambaumeister commented Aug 9, 2018

As far as I know there is no method to route individual secrets backends to a specific audit method which means youd be turning of hashing within auditing altogether, which wouldn't be so good. I could be wrong?

@jefferai
Copy link
Member

@jefferai jefferai commented Aug 9, 2018

Setting that would turn off hashing the serial number for that particular mount for all audit methods, yes. But serial numbers are not generally sensitive anyways.

@darrylweaver
Copy link

@darrylweaver darrylweaver commented Sep 25, 2019

Such a shame, we would also have adopted Vault for SSH key management, except that this feature is not available and the only answer given is that your use case is not a valid one and it has been left for 2 years.

But the PKI secrets backend has an automatically generated CRL for that use case and the same mechanism for SSH would have allowed us to adopt it.

@pescobar
Copy link

@pescobar pescobar commented Oct 27, 2019

After reading the comments in this issue I guess the answer is NO but I will ask just in case....is there any way to implement something like this using hashicorp vault? or any plan to add this feature?

https://github.com/nsheridan/cashier#revoking-certificates

@jefferai
Copy link
Member

@jefferai jefferai commented Oct 27, 2019

@pescobar it's not currently on the internal roadmap to add this but it might at some point. An interested community member could maybe work with someone on the Vault team to implement this. However I don't think that this backend currently stores issued certs. If not we don't have any current way of knowing any cert details.

One really key thing here is that for an X509 certificate a crl must be signed. That's not the case for SSH certificates. So vault creating a file for you is convenient but by no means a requirement because you don't need access to the private key to generate it.

@kaizen1
Copy link

@kaizen1 kaizen1 commented Dec 22, 2019

I also find this a really nice to have feature. If revocation cannot be done, we should at least have a way to list all the certificates that are signed. It's easy to lose track if you work with long living certificates...

Exactly. The whole point of centralized management is to be able to revoke access, regardless of TTL. People go rogue in milliseconds, not minutes or hours. It's a gaping hole.

@jefferai
Copy link
Member

@jefferai jefferai commented Dec 22, 2019

You can't revoke access with Vault, because unlike the internet PKI, SSH KRLs have no distribution mechanism -- there's nothing like CRL Distribution Points. Given that you must perform all distribution yourself and that no signature is used for KRLs there's little for Vault to do here.

Listing issued certificates could maybe be added although it's not a super trivial lift. I'm going to close this ticket though as it's about CRLs and there isn't a clear path forward that leverages Vault.

If you want to have Vault store cert information for later listing please open a ticket for that.

Otherwise my suggestion is to simply not use long lived certificates. Vault can handle issuing a certificate per connection, so making certificates very short is a good way to limit later connections without current authorization.

@jefferai jefferai closed this Dec 22, 2019
@kquinsland
Copy link

@kquinsland kquinsland commented Jun 1, 2021

I also find this a really nice to have feature. If revocation cannot be done, we should at least have a way to list all the certificates that are signed. It's easy to lose track if you work with long living certificates...

Exactly. The whole point of centralized management is to be able to revoke access, regardless of TTL. People go rogue in milliseconds, not minutes or hours. It's a gaping hole.

This is precisely the scenario that I'm most curious about:

For reasons that are not relevant here, I need a SSH key to be valid for at least 12h, ideally up to 36h. A human will be using this ssh key and will likely have long-running connections. Think tail -f /var/log/.... kinda thing.

If this hypothetical human is let go 24h after their certificate is issued, i would really like to void out the last 12h that the cert is good for ASAP.

A related situation:

A routine process requires SSH between nodes to function. E.G.: routine_process.sh running on node00 will ssh into node01 and node02 ... etc to run some commands. The commands could finish in as little as 15 min or could be running for literal days. If Im understanding this thread correctly, I would have to assume that each SSH connection will take days and so I should allocate a SSH certificate that's good for several days. I have no way to revoke that certificate early if the process only took a few hours.

@Fuco1
Copy link

@Fuco1 Fuco1 commented Jun 9, 2021

So many platforms completely ignore the CRL and revocation with certificates that I wonder if anyone actually uses any of this in production. I got burned with traefik before and now with vault again. Any sort of certificate scheme is completely unusable without revocation. Expiration is not a mitigation strategy.

Of course you can always rotate all your CA certs... basically revoking everyone's access all at once. /shrug

@selurvedu
Copy link

@selurvedu selurvedu commented Jun 9, 2021

@kquinsland the validity is only checked when the connection is being estaished. E.g. you can have a CA signature that's valid for 30 seconds but use it for a long-running session. That's what Vault does by default.

@kquinsland
Copy link

@kquinsland kquinsland commented Jun 9, 2021

@selurvedu I was able to confirm that during some testing... and then discovered that uber created a PAM module to solve exactly that problem.

My point about being able to immediately revoke a certificate that has yet to expire still sands though. I am contemplating w/ doing just that; a root CA re-issue, but there are some users / internal tools that may have disrupted workflows.

@selurvedu
Copy link

@selurvedu selurvedu commented Jun 9, 2021

@kquinsland Yes, that issue remains. There are solutions like https://goteleport.com/blog/ssh-certificates/#rotate-ca-keys but they require you to switch from Vault to something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet