5 ms·

Am author. > chef/puppet/etc ... put just your pubkeys somewhere (S3, eg) ... Yea, cool, and now you have a second authentication system that you have to manu

Am author. > chef/puppet/etc ... put just your pubkeys somewhere (S3, eg) ... Yea, cool, and now you have a second authentication system that you have to manually administer to onboard and offboard people. And you have permanent long-lived single-factor credentials on a bunch of (possibly unmanaged) endpoints, that are easy to exfiltrate, and are a common target for attackers if a laptop is lost/stolen/compromised. You haven't addressed host name reuse or host rekeying which, again, are real operational problems. And somehow running and administering chef/puppet/etc or this S3 bucket is easier than running a simple certificate signing service connected to SSO that requires basically zero maintenance once it's setup? Argumentative, at best. > Next problem is that openssh-style certs do not support cert chains ... recover from compromise. Since only hopeless organizations don't have config management, we can solve this there. SSH PKI is simple and doesn't have intermediates. But you can configure multiple roots. To rotate or revoke a compromised private key you'd simply deploy a new root using cert management and issue new certificates. In a non-emergency situation you can slowly roll certificates by having two trusted roots for a transitional period while everyone gets new certs. > You have to secure the CA! You have to secure your configuration management that's deploying public keys everywhere and your authorized keys files on every host! Pubkey distribution has a bigger attack surface area and the same exact compromise consequences as a CA. This is not even a contest. > You have to properly authorize signing requests! You have to authorize requests to deploy public keys! There are tools for this. What's the hard part here? Verifying an OIDC identity token? Mapping a token subject to an SSH principal? Worst case, you could keep whatever crappy manual process you have for authorizing public key distribution and issue a certificate instead. > These things fall into the realm of hard. Ok, I guess? This is all relative. It's easier than pubkey authentication at any non-trivial scale. There's a difference between something being hard vs. being unfamiliar.

jiveturkey 7y ago
> and now you have a second authentication system ... [and a host of other problems] You have that anyway. I wasn't suggesting to dump authorized_keys into S3 if you aren't already using S3. I was just using a throwaway example. Any large enough environment to care, is large enough to need to manage this type of resource as a sunk cost. > somehow running and administering chef/puppet/etc or this S3 bucket is easier Yes, because it's a sunk cost, and mandatory anyway, outside of any ssh consideration. Any org should be striving to do less things, not more things. > simple certificate signing service there's no such thing > configure multiple roots You got me there. That is a reasonable enough solution. Of course your 'backup' root has to be offline, but that's the same as with an intermediate. I could probably manufacture a case where having a cert chain is easier but since it's not obvious to me at a moment, I'm sure would be pretty contrived. But, aren't you getting farther and farther away from simple? > You have to secure your configuration management that's deploying public keys everywhere and your authorized keys files on every host! True. However, that's a sunk cost. You have to do that anyway. > Worst case, you could keep whatever crappy manual process you have for authorizing public key distribution and issue a certificate instead. Then why bother with the cert at all? Also, you are insisting that an org's manual process is crappy. If your process for pubkey authz and distribution is crappy, you have crappy practices and it's a sure thing your shiny new CA is a huge liability as another crappily deployed and crappily maintained system. > It's easier than pubkey authentication at any non-trivial scale. Well, I dispute that. At large scale you have even better config mgmt and if you're doing it right, can handle either way. CA is still probably better because the benefit to you at large scale is not relief from managing pubkey resources, it's from being able to do short-lived certs as well as an easier route to tighter authz. At moderate scale, get real, these things aren't a concern. Your main problem isn't that you're wrong, it's that your absolutist view of it is a distortion. (Which makes it wrong.)

jiveturkey 7y ago

> and now you have a second authentication system ... [and a host of other problems] You have that anyway. I wasn't suggesting to dump authorized_keys into S3 if you aren't already using S3. I was just using a throwaway example. Any large enough environment to care, is large enough to need to manage this type of resource as a sunk cost. > somehow running and administering chef/puppet/etc or this S3 bucket is easier Yes, because it's a sunk cost, and mandatory anyway, outside of any ssh consideration. Any org should be striving to do less things, not more things. > simple certificate signing service there's no such thing > configure multiple roots You got me there. That is a reasonable enough solution. Of course your 'backup' root has to be offline, but that's the same as with an intermediate. I could probably manufacture a case where having a cert chain is easier but since it's not obvious to me at a moment, I'm sure would be pretty contrived. But, aren't you getting farther and farther away from simple? > You have to secure your configuration management that's deploying public keys everywhere and your authorized keys files on every host! True. However, that's a sunk cost. You have to do that anyway. > Worst case, you could keep whatever crappy manual process you have for authorizing public key distribution and issue a certificate instead. Then why bother with the cert at all? Also, you are insisting that an org's manual process is crappy. If your process for pubkey authz and distribution is crappy, you have crappy practices and it's a sure thing your shiny new CA is a huge liability as another crappily deployed and crappily maintained system. > It's easier than pubkey authentication at any non-trivial scale. Well, I dispute that. At large scale you have even better config mgmt and if you're doing it right, can handle either way. CA is still probably better because the benefit to you at large scale is not relief from managing pubkey resources, it's from being able to do short-lived certs as well as an easier route to tighter authz. At moderate scale, get real, these things aren't a concern. Your main problem isn't that you're wrong, it's that your absolutist view of it is a distortion. (Which makes it wrong.)