On Thu, 2020-01-30 at 17:06 +0000, Brian Candler wrote: > On 30/01/2020 16:48, Christian, Mark wrote: > > > However, when alice is no longer authorized, and assuming her > > > cert is > > > still valid, you're going to want to use some configuration mgmt > > > to > > > manage RevokedKeys, otherwise ensure that alice's cert is valid > > > for a > > > short period of time. > > Indeed: I was intending to use a cronjob to fetch a CRL, as suggested > at > > https://github.com/nsheridan/cashier#revoking-certificates > > > > AllowGroups, AllowUsers in sshd_config. /etc/security/access.conf > > or > > equivalent. These are the ways to limit access to systems where > > bob > > and alice are not authorized. > > So if I understand you correctly, you're saying "SSH certificates are > not intended to be used to carry authorization information". No, SSH certificates can be a perfectly suitable authorization solution, but that doesn't mean you shouldn't also use the other authorization mechanisms at your disposal. You have plenty of options. Nothing says that your entire authorization scheme must take place within openssh. Leverage PAM, use access.conf. Get creative. Mark > > In general, there is a sound argument for keeping authentication > separate from authorization. On the other hand, it does make me > wonder why there is support for multiple principals in one SSH > certificate. > > Regards, > > Brian. > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
