Re: SSH resources, specifically on certificates (certificate authentication)
Dan Purgert wrote:
> On Jul 13, 2022, David Wright wrote:
> > On Wed 13 Jul 2022 at 18:40:18 (-0400), Dan Purgert wrote:
> > > On Jul 13, 2022, rhkramer@gmail.com wrote:
> > > > I seem to have gone down a rabbit hole.
> > > >
> > > > I want(ed?) to set up ssh on my LAN using certificate authentication, and am
> > > > having a lot of trouble finding the information I need / would like to have.
> > >
> > > Which is what, exactly? Other than the "active mailing list" you
> > > mentioned in a snipped segment.
> > >
> > > SSH with cert-auth is pretty trivial to implement on most distros:
> > >
> > > 1. install openssh-server (if not already installed) on SERVER (the
> > > machine you will connect to)
> > > 2. on the CLIENT (machine you will connect from), run ssh-keygen to
> > > generate a new ssh keypair. For example -- ssh-keygen -t ed25519 -f
> > > keyfile -- will generate a new ED25519-based keypair ("keyfile" and
> > > "keyfile.pub").
> > > 3. copy the content of keyfile.pub to $HOME/.ssh/authorized_keys on the
> > > SERVER machine
> > > 4. try logging into SERVER with your key (e.g. ssh -i keyfile
> > > user@SERVER)
> > >
> > > For "best security" repeat steps 2-4 on all CLIENT machines to create
> > > individual client keys -- just make sure to APPEND to authorized_keys.
> >
> > That's what I do, but that's /key/ authentication, not cert.
> > (Search for "certificate" in man ssh-keygen to see what's
> > involved with certificates.) I'm afraid I'm not up to speed
> > on that topic.
>
> *sigh* indeed, I crossed my thinking. :(
>
> Should be basically the same -- at least the manpages for ssh and
> ssh-keygen cover it pretty well...
>
> ssh-keygen -s /path/to/ca -I keyid /peth/to/user_public
>
> sshd apparently needs a "cert-authority" parameter set at start-time, so
> that it knows the signing CA for the certs, and then you (apparently)
> configure authorized_keys in the same manner.
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-
Reply to: