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.
On 31/01/2020 14:29, Michael Str?der wrote:> 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.I thought that was the point of the certificate "identity" (-I) in addition to the "principals" (-n).? The login shows the certificate identity: Jan 30 11:50:49 test1 sshd[4757]: Accepted publickey for alice from 2001_db8::2009 port 56943 ssh2: RSA-CERT ID brian (serial 1) CA RSA SHA256:fofx2XMj+RqnLlui09aDIuV9fWqPiU54oWStDzYr/p0 In this case, the cert identity was "brian"; cert principals were "alice" and "www"; ssh login was as user "alice". It's still a good idea to keep track of all issued certs though, in case you need to revoke one. Regards, Brian.
On 1/31/20 3:52 PM, Brian Candler wrote:> On 31/01/2020 14:29, Michael Str?der wrote: >> 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. > > I thought that was the point of the certificate "identity" (-I) in > addition to the "principals" (-n).? The login shows the certificate > identity: > > Jan 30 11:50:49 test1 sshd[4757]: Accepted publickey for alice from > 2001_db8::2009 port 56943 ssh2: RSA-CERT ID brian (serial 1) CA RSA > SHA256:fofx2XMj+RqnLlui09aDIuV9fWqPiU54oWStDzYr/p0 > > In this case, the cert identity was "brian"; cert principals were > "alice" and "www"; ssh login was as user "alice".Ah, ok. Description of semantics in ssh-keygen(1) is not really clear so currently I've just set a UUID for each new key pair. But I could prefix this with a user name.> It's still a good idea to keep track of all issued certs though, in case > you need to revoke one.Or better get rid of the revocation requirement. ;-) Ciao, Michael.