On 1/30/20 5:48 PM, Christian, Mark wrote: > On Thu, 2020-01-30 at 16:37 +0000, Brian Candler wrote: >> I was hoping to avoid the dependency on configuration management by >> carrying the authorization in the certs themselves - if that is in >> the spirit of the SSH cert mechanism. > > Sign alice and bob's ssh cert with principal's alice,www and bob,www > respectively. Configure sshd_config so that individuals don't require > an authorizedprincipalfile, and use Match within sshd_config for any > "service/faceless" account like www, to force use of an > authorizedprincipalfile. The contents of www's authorizedprincipal > file will simply contain the principal "www" or whatever you > choose. This should limit configuration mgmt dependency. Hmm, personally I'd recommend not to issue user certs for generic user names (e.g. "www"). While some cert information is logged by sshd it requires keeping track of all issued certs in searchable data store to be able to properly map logins to personal user accounts during an audit. > 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. Again this requires to keep track of issued certs which need revocation in case the authorization changes. Sounds too complicated to me. => Use a decent user management (not config management) for managing authorization based on user and host groups. Ciao, Michael. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
