[daave]

This is a non-sequitur, even if you use SSH certificates you still need a public/private keypair, hosts just authorize the key by checking the signature from a trusted CA on the public half of the user key. The OP is about a way to store the private key part of the user key that can't be extracted even with physical access to the machine. So, this is an equivalent/alternative to using a YubiKey, that is conveniently built in to a popular piece of hardware; not something orthogonal to using SSH certificates.

[tptacek]

It's not really a non-sequitur. The idiom for SSH certificates is to be issued extremely short-term certificates in response to MFA authentication. You don't get long-term secrets in most SSH CA schemes.

[daave]

You're certainly more of an authority on it than I, so I trust when you say most schemes don't keep long-term keypairs around; but of the two companies I've worked at that use SSH CAs: one used Teleport, and the other had long-lived keypairs, but fairly-short-lived certificates -- you had to get your public key re-signed each day. They used Yubikeys to store (or maybe just unwrap?) the private key material during the SSH handshake; much as a TPM or the Secure Enclave could be used to do this.

[camgas]

My experience (over maybe 10 years of using SSH-CAs) was similar, I mean by using long-term key pairs (mostly for humans) and shorter certificates. I can imagine secretive to be a very useful tool for SSH-CAs and other uses. I also like the fact that you can't import a key, makes it pretty clear that A- it's a specific device, and B- there is a human adding their bio info to unlock it.

[tptacek]

Your experience of SSH CAs is different from mine (that doesn't make it wrong). My experience is that the major motivation for SSH CAs is linking SSH authentication to MFA SSO. The long-lived secrets here are the MFA secrets.

[camgas]

Very useful to know, thanks for explaining more. I am curious to know (if you happen to remember) if this was an off-the-shelf product, and if so which one? I assume the product was either an MFA device or an SSH/SSO solution or both.

[tptacek]

I've worked with teams that did bespoke versions, but Teleport is the most popular implementation of the idea right now. The underlying idea is trivial, right? You have an SSO RP that is a CA, and issues short-lived certs based on SSO IdP logins; the simple SSH certificate machinery makes this work across your fleet.

[blueflow]

The certs are just an alternative to managing the authorized_keys server-side. That's it. What you said about MFA and not getting long-term secrets is some extra thing on top of it and not invalidating your parents point.

[tptacek]

No, that's not true. SSH keys are long-lived secrets, and certificates often deliberately aren't.

[blueflow]

This is not what it is, this is how you specifically use them.

[tptacek]

I understand what you're trying to say, but "The certs are just an alternative to managing the authorized_keys server-side" is just not correct. Certs can do things plain authorized_keys can't.