On Mon, 2020-06-01 at 11:47 -0700, Peter Moody wrote: > i might be misunderstanding the question, but wouldn't something like > this work? > > Match Group unprivileged > TrustedUserCAKeys /etc/ssh/unprivilged_pub_key > > Match User root > TrustedUserCAKeys /etc/ssh/priviledged_pub_key Yes, this would work. Feeling a little sheepish at the moment =). Thank you, Mark > > On Mon, Jun 1, 2020 at 11:36 AM Christian, Mark > <mark.christian@xxxxxxxxx> wrote: > > Wondering if it would make sense to have more granular control of > > trustedUserCAkeys? I have 1 key used to sign root certs, the key > > is > > shortlived, and is rotated daily. And I have a 2nd key to sign > > non- > > privileged user certs. The non-privileged certs have a longer > > validity > > period, and the signing keys are not rotated as frequently. It > > would > > be nice to ensure this second signing key's associated pubkey in > > trustedusercakeys is never consulted when a root certificate is > > presented, perhaps via some form of blacklisting within the > > trustedusercakeys file? This would provide some assurance that the > > theft of the second key could not be used to sign root certificates > > and > > be accepted for the systems I manage. > > > > Mark Christian > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev@xxxxxxxxxxx > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
