top | item 45756595

(no title)

waste_monk | 4 months ago

>That way when your CA private key leaks (the key which we never ever rotate, of course)

As with X.509, any serious usage will involve a hardware security module, so that compromise of the CA host does not allow the key to be leaked. You'd still have a very bad day, but it can be mitigated.

I do think it's a fairly significant flaw that SSH CA doesn't support intermediate CA's (or at least didn't last time I looked into it) to enable an offline root CA.

>Bonus points if the same CA is also used for authenticating users.

The SSH CA mechanism can be used for both Host and User auth, yes.

Keeping in mind, in a real use case this would be tied to something like active directory / LDAP, so you can automate issuance of ssh keys to users and hosts.

Systems configured to trust the SSH CA can trust that the user logging in is who they say they are because the principal has already been authenticated and vouched for by the identity provider, no more manually managing known_hosts and authorized_keys, or having to deal with Trust On First Use or host key changed errors.

You can also set the CA's endorsement of the issued keys to fairly short lifetimes, so you can simplify your keymat lifecycle management a great deal - no worrying about old keys lying around forever if the CA only issues them as valid for an hour / day / etc. .

Overall I think you still come out ahead on security.

discuss

order