Re: SSH resources, specifically on certificates (certificate authentication)
On Thu, Jul 14, 2022 at 8:56 AM <rhkramer@gmail.com> wrote:
>
> <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-
>
> --
SSH certificate authentication is not complicated and has many
advantages. Some organizations use SSH certificates to provide limited
access for admins to servers. In my opinion using SSH certificates is
preferred to just using ssh keys. There are a number of guides on how
to implement ssh certificates - if you are unable to locate, ping me
directly and I may have a document I wrote for myself a while back.
Best,
Frank
Reply to: