> If you are constantly regenerating uncompromised SSH keys, you are probably doing something wrong.

Yup, there's no real reason to generate a new SSH key pair each and every time you want to get a short lived certificate. The SSO or CA management system (like Vault) is responsible for verifying your identity.

This is also true for X.509, there is exactly zero reason to generate new key (if it was not compromised) or even new CSR for certificate renewal. Yet people tend to do this which only increases the opportunities to fuck something up in the process. (Well, it does not make much sense, but over last year I have seen at least three instances of somebody overwriting the only copy of newly generated private key with the old one…)

> This is also true for X.509, there is exactly zero reason to generate new key (if it was not compromised) or even new CSR for certificate renewal.

It might make sense to regenerate the private key on each certificate renewal if the private keys are kept unencrypted, as they often are in the X.509 scenario. If the keys are encrypted and if your web server manages to get the password to decrypt that key each and every time it serves a request, then yeah, I don't see the point of regenerating the private key on certificate renewal.

One of the first things the article mentions is rekeying. Since the step utility does in fact regenerate keys when obtaining certificates, it actually does have a lifespan. Besides, how do you even tell that your keys have been compromised?

> One of the first things the article mentions is rekeying. Since the step utility does in fact regenerate keys when obtaining certificates, it actually does have a lifespan.

I went through the article again. Essentially, rekeying makes sense if the private keys in question, whether they are host private keys or client private keys, are kept unencrypted on disk. Host private keys typically are, so it might make sense to rekey host private keys. However, if your user private key is kept encrypted on disk, as it should be, there isn't really a good reason to rekey.

The step tool seems to abstract that process and it also generates a new key pair on each login but that keypair never even touches the disk, according to the article. This makes sense assuming the step tool generates a key pair and doesn't encrypt the private key. In that case, yes, rotating/regenerating the client keypair on each login make sense.

Those are choices made by the Smallstep SaaS and are not reflective of the underlying SSH cert technology.

The thing is, the topic of the article centers around the step utility and security practices that it considers is the best. My comments were in relation to the article, not all the possible ways in which SSH certificates can be used.