<Intentionally top posting> dsr, Thanks for the reply!
Like I said, I think I went down a rabbit hole, and I wish I had realized that before I went there. I've invested quite a few calendar days (and "spare" manhours) in trying to figure this out, so I'm not quite ready to give up. I do have some ideas (an idea) for another pass through some of the documentation that might clarify what I need / want to know, but, especially if that doesn't work, I may write a WikiLearn page or two that mainly just warns about the rabbit hole. I'm almost certain I will be back with some specific questions that maybe you or someone else on the list can answer. Thanks again! On Thursday, July 14, 2022 02:11:30 AM Dan Ritter wrote: > Dan Purgert wrote: ... > > > > On Jul 13, 2022, rhkra...@gmail.com wrote: > > > > > I seem to have gone down a rabbit hole. > Right, the problem is in everything to support that: running a > certificate authority in a secure manner is extremely > non-trivial. Running it in a secure and reliable manner is even > more non-trivial. > > In general, I don't recommend it. Consider this: > > - an SSH certificate has a date on which it will expire. When > that day comes, it will stop functioning. If you don't have > infrastructure to remind you to re-issue this in advance, you > may be locked out of whatever you are trying to access. > > - conversely, if you want to revoke an SSH certificate before > the expiration date, you need to maintain and distribute a > revocation list of all the certs that you no longer approve of. > Miss a machine and the old cert is still valid up to the > expiration date. > > For most people in most cases, those are not the behaviors that > they want. > > > I've never seen this implemented in any place I've worked in > > the last 2 decades (granted, I "only" have said 2 decades of > > "professional" experience); rather they've always used either (a) keys, > > or (b) password + RSA Token (or other 2FA / TOTP mechanism) > > And the reason is that those fit what people want more closely > than the cert mechanism. > > If you've got a very large organization, you may want to support > the infrastructure to generate new SSH certs for people daily, > with expiration dates of 24 hours. Then you need to make sure > that mechanism is working perfectly and has appropriate > redundancy, so that you don't accidentally lock out the whole > organization tomorrow. > > -dsr- -- rhk If you reply: snip, snip, and snip again; leave attributions; avoid top posting; and keep it "on list". (Oxford comma included at no charge.) If you change topics, change the Subject: line. A picture is worth a thousand words -- divide by 10 for each minute of video (or audio) or create a transcript and edit it to 10% of the original.