Re: SSH resources, specifically on certificates (certificate authentication)
<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, rhkramer@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.
Reply to: