[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: