Can SSH user certificates be renewed?

[anon8675309]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to document this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

SSH user cert renewal

I would like documentation on how to renew SSH user certs in a similar way to how SSH host certificates are renewed: non-interactive and without any secrets other than having a signed cert and the corresponding key. This would allow short certificate lifetimes.

Here's what I did find and why it does not meet my requirements:

• a playbook that issues a new SSH user cert using a one-time-use token; no renewal information
• step ssh renew which seems like it should be the command to use, but it explicitly says "This command cannot be used to renew SSH User Certificates."
• the experimental nebula provider which is the only provider in the list that claims to be able to do a ssh-user-cert-renew; no info on how to renew a user SSH cert, only on how to obtain an X509 cert
• a comment in a discussion which says that, as of 2021, renewal of SSH user certificates was not implemented. Since the aforementioned table documents Nebula as being able do this, I believe that the comment is now outdated

I'd expect to find this in the documentation on how to renew SSH user certs in all of the following locations:

• Documentation on the nebula provider which can reportedly do this
• The example playbook
• The step ssh renew documentation if that command is extended to handle this

Some information about my use case, in case it is helpful:

• Each server has its own SSH user cert, username is the FQDN
• The backup servers trust SSH user certs
• Each backup server has an account for each FQDN that needs to stash their backups there
• I don't want the CA password to live on every server, as that'd let a compromised server obtain a certificate that belongs to another host (among other things)
• SSH user certs are issued at deployment time using ansible.builtin.command, like so:
  • step ssh certificate {{ansible_fqdn}} .ssh/id_ecdsa --provisioner={{ca_user}}@{{ansible_domain}} --password-file={{ca_password_file}} --no-agent --force
• Using borg backup, which only supports writing to remote hosts via SSH, so mTLS isn't an option short of extending borg backup
• Short certificate lifespans are preferable to long ones
• Having access unexpectedly cut off when a cert expires is bad, and even worse when it's cut off for an automated system

[dopey]

Hey @anon8675309 👋 . Thanks for opening the issue!

As you mentioned step-ca does not support renewing SSH user certificates (I'm not familiar w/ the Nebula provisioner so maybe @maraino can chime in as to why Nebula would be a special case here).

It has been a while since we made this decision but I'll do my best to remember our reasoning. X509 has a widely used process for revoking certificates - CRL. SSH has the KRL but at the time when we made this decision, KRLs were not widely used. I'd have to do some research to understand how common they are now and how well supported. A certificate that can renew itself using it's own private key is essentially a never expiring credential (especially when there is no easy to use system for revoking and checking revocation status). As a policy we prefer not to issue non-expiring credentials to users or workloads that generally only need that credential for a short period of time.

When describing your use case you mention that your hosts need SSH user certificates (I assume for workflows that involve connecting to other hosts). Our philosophy for this use case is that these SSH User ("bot") certificates should be generated on demand when needed by workflows. One way to do this is by issuing the host a longer lived X509 certificate (using a Cloud Identity provisioner, a JWK provisioner, or a ACME Device Attestation provisioner) and then using this X509 certificate in the X5C provisioner to generate SSH user certificates on demand (this is a pattern we use in our hosted platform). We consider this X509 certificate the hosts "Identity" or "Device" Certificate. This Device Certificate can renew itself (you can set up a daemon to do this), and can generate X509 and SSH credentials for all the workloads that reside on the host.

[maraino]

The problem is that x5c sign doesn't work for P-384 and P-521 curves because there's a bug in a library that we use that returns a list of algorithms that we can use, and we pick the first one, that in this case is ES256, instead of the one specific for the key that should be ES512.

So I'll fix it and also submit a PR to go-jose to be more specific.

[maraino]

@anon8675309 This should fix the problem smallstep/cli#897

[maraino]

If you compile step from the master branch it should work for you, with the version you have it will work for ECDSA P-256, Ed25519, and RSA keys.

[anon8675309]

I have compiled the latest code for cli and can confirm that it seems that patch has resolved my issue!

Do you expect this to land in 0.23.5, or is it more likely to be in 0.23.6?

[maraino]

It will be in the next release.

[maraino]

Hi @anon8675309, the only way to renew an SSH certificate is using SSHPOP provisioner, and this is only enabled for host certificates. So the table that you mention incorrect, @tashian can you take a look to this.

But you can re-use the same key to get a new certificate using any provisioner, for example like this:

1. Create and sign a new key (it will create mariano, mariano.pub, and mariano-cert.pub):

step ssh certificate [email protected] mariano

2. Re-sign using the same public key:

step ssh certificate --sign [email protected] mariano.pub

[maraino]

Of course, if you're using a nebula certificate, you will need the --nebula-cert and --nebula-key flags too.

[maraino]

I've created this smallstep/docs#190