0

tl;dr: In certificate based SSH authorization, is there any benefit to keeping host certificates lifespan short? Do you gain anything by renewing them periodically?

Full Story
Recently I have been exploring SSH access through certificates, as opposed to the traditional means of access through public key authentication.

To me, certificate based authentication makes a lot of sense in terms of scalability and security, especially when paired with some kind of authorization with an identity platform like Active Directory. Making short lived user certificates eliminates the need for one to keep track of where their public keys live and creates narrower attack windows for any malicious actors. However, one pattern that I have seen a couple of times now is also creating short lived host certificates that are periodically renewed.

While I understand that host certificates are great because they can eliminate TOFU related issues, I am struggling to understand why I am seeing the pattern of short lifespans with frequent renewal. If anyone has insight to scenarios where this would be useful, I would greatly appreciate the explanation.

Note: Just to eliminate any ambiguity, what I mean by user and host certificates is as follows:

  • user: The certificate belonging to the client which initiates the SSH connection.
  • host: The certificate belonging to the server which is the target for the SSH connection.

1 Answer 1

1

One theory of certificates is "Renew often, and you won't get bitten by renewal."

A higher tempo of renewals means either humans are practiced in the steps required, or they've automated it (a la Let's Encrypt); either way the renewal is expected to go smoothly. By comparison, when renewal was multi-years, manual process, a lot of companies got bit by not knowing what they were supposed to be doing when the time rolled around.

This practice may be driving the short renewals you're seeing on host certificates.

Because SSH host certificate checking relies on the CA approval, it doesn't experience the same Trust On First Use (TOFU) problem that SSH host keys have.

Note: This article argues that certificate lifetimes should be short, on the order of hours, so that a compromised certificate can only be abused for a short time. As above, this depends on an automated process for rolling out certificates. See the section titled "Making time work for you".

4
  • This is a good answer for SSL because there is a centralized mechanism for updating certs (and as you noted, that can be paired with automated renewals with Let's Encrypt). SSH doesn't have that mechanism, so updating your key will result in what looks like a MitM attack to users. More detail in my answer.
    – Adam Katz
    Sep 2, 2021 at 15:06
  • @AdamKatz you are correct for host keys but we're talking about host certificates. To quote, "Static keys in ~/.ssh/authorized_keys are no longer needed. Instead, peers learn one another’s public keys on demand, when connections are established, by exchanging certificates. Once certificates have been exchanged the protocol proceeds as it would with public key authentication." It is verification through the CA, not the host fingerprint, that matters; the TOFU problem goes away.
    – gowenfawr
    Sep 2, 2021 at 17:21
  • @AdamKatz I added some text to distinguish certificates from keys for this use case, hopefully that's helpful.
    – gowenfawr
    Sep 2, 2021 at 17:53
  • Thanks for the clarification, I had missed the keys vs certs distinction.
    – Adam Katz
    Sep 2, 2021 at 17:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .