Christian, Mark
2020-Jun-01 18:33 UTC
would it be possible to extend TrustedUserCAKeys so that certain keys could not be used to authenticate a particular user?
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
Peter Moody
2020-Jun-01 18:47 UTC
would it be possible to extend TrustedUserCAKeys so that certain keys could not be used to authenticate a particular user?
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 On Mon, Jun 1, 2020 at 11:36 AM Christian, Mark <mark.christian at intel.com> 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 at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Christian, Mark
2020-Jun-01 18:55 UTC
would it be possible to extend TrustedUserCAKeys so that certain keys could not be used to authenticate a particular user?
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_keyYes, 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 at intel.com> 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 at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev