On 30/01/2020 15:02, Christian, Mark wrote:> On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote: >> As a concrete example: I want Alice to be able to login as "alice" >> and >> "www" to machines in group "webserver" (only). Also, I want Bob to >> be >> able to login as "bob" and "www" to machines in group "webserver" >> (only). > Why can't you have a AuthorizedPrincipalsFile for alice, bob and www on > each of the "web servers", where the contents of the alice file include > the principal name alice, the contents of the bob file contain the bob > principal, and the contents of the www file contain the contents alice > and bob? Wouldn't that allow alice to ssh as alice, and www, and allow > bob to ssh as bob and www to any machines that had this > authorizedPrincipals file configuration?Yes, that would work, but then it comes back down to configuration management to push out all authorizations (and? more importantly, remove them when no longer authorized).? If you're going to do that, it's not too far removed from pushing out ~/.ssh/authorized_keys for each user. 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. On 30/01/2020 16:05, Michael Str?der wrote:> Adding authz information to user certs means that you need to renew the > cert if the authz information changes during cert life-time. This can be > annoying for users. > > How long should your user certs be valid?I think on an initial implementation I'd go with 3-month certs, perhaps using a PKCS#11 token like a Yubikey.? You're right that if we have to change the authorization for a user, they'd need a new cert. Eventually it would be nice to move to daily certs with online login (e.g. cashier, step-ca) in which case anyone who needs a new cert can get it themselves instantly.? The main thing stopping me from doing this straight away is your other point:> You have to maintain this user-hostgroup relationship somewhere. Is it > possible for your system to query this information?The inventory system tracks hosts rather than users, but I don't see a big problem putting the user-group relationship into LDAP, even if it only writes out a flat file periodically. However, the system which issues the certs needs to be able to do the mapping from OIDC claims to SSH cert principals.? I've just been looking at step-ca and I don't see a way to do that.? I haven't looked at cashier yet, and I only just learned of gsh. Regards, Brian.
On Thu, 2020-01-30 at 16:37 +0000, Brian Candler wrote:> On 30/01/2020 15:02, Christian, Mark wrote: > > > On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote: > > > As a concrete example: I want Alice to be able to login as > > > "alice" > > > and > > > "www" to machines in group "webserver" (only). Also, I want Bob > > > to > > > be > > > able to login as "bob" and "www" to machines in group "webserver" > > > (only). > > > > Why can't you have a AuthorizedPrincipalsFile for alice, bob and > > www on > > each of the "web servers", where the contents of the alice file > > include > > the principal name alice, the contents of the bob file contain the > > bob > > principal, and the contents of the www file contain the contents > > alice > > and bob? Wouldn't that allow alice to ssh as alice, and www, and > > allow > > bob to ssh as bob and www to any machines that had this > > authorizedPrincipals file configuration? > > Yes, that would work, but then it comes back down to configuration > management to push out all authorizations (and more importantly, > remove them when no longer authorized). If you're going to do that, > it's not too far removed from pushing out ~/.ssh/authorized_keys for > each user. > > > 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. 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. Mark
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". 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.
On Thu, 30 Jan 2020, 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.AFAIK most organisations that use ssh certificates give them short (~1 day) lifetimes to avoid the risk of lingering authority, but it's still useful to have a tested revocation path for the odd case where you actively need to kill a key/cert. -d
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 1/30/20 5:37 PM, Brian Candler wrote:> On 30/01/2020 16:05, Michael Str?der wrote: >> Adding authz information to user certs means that you need to renew the >> cert if the authz information changes during cert life-time. This can be >> annoying for users. >> >> How long should your user certs be valid? > > I think on an initial implementation I'd go with 3-month certs, perhaps > using a PKCS#11 token like a Yubikey.? You're right that if we have to > change the authorization for a user, they'd need a new cert.That's a pretty long period. So you MUST deal with decent revocation leading to lots of nasty user-facing processes. While on the server-side you might have the simple idea for the usual wget CRON job you would have to monitor whether it functions correctly on each target system. After all revocation is then a critical part of your access control. Furthermore you have to deal with informing the user about having to get a new updated cert. But the client-side information is pretty terse. For the user the SSH login just fails. And you have to get rid of stale key pairs in ssh-agent. Otherwise you might hit MaxAuthTries limit. Personally I cannot imagine how you want to implement all this with a decent UX to avoid support requests. (BTW: yubikey is slow. So if you have admins accessing many machines in one go you will get a notable latency during first SSH connection.)> Eventually it would be nice to move to daily certs with online login > (e.g. cashier, step-ca) in which case anyone who needs a new cert can > get it themselves instantly.? The main thing stopping me from doing this > straight away is your other point: > >> You have to maintain this user-hostgroup relationship somewhere. Is it >> possible for your system to query this information? > > The inventory system tracks hosts rather than users, but I don't see a > big problem putting the user-group relationship into LDAP, even if it > only writes out a flat file periodically. > > However, the system which issues the certs needs to be able to do the > mapping from OIDC claims to SSH cert principals.After reviewing many of the existing SSH-CA implementations for issuing short-term user certs I've implemented my own (client and server). The main reason was I wanted to be able to adapt it to whatever requirement I will have in the future for integrating it with the customer's user management (and my own LDAP-based user management). Ciao, Michael.
On 31/01/2020 15:37, Michael Str?der wrote:> (BTW: yubikey is slow. So if you have admins accessing many machines in > one go you will get a notable latency during first SSH connection.)I meant using a single Yubikey as the CA sign the certificates. I'm thinking of an organization where the number of admins is in the low tens.? The end-game of having daily keys and certs loaded directly into ssh-agent is very appealing, but I'm not sure we're ready to jump right there yet.? Getting people over to certs and starting to rip out ~/.ssh/authorized_keys is an important first step. As for the freshness of the CRL file: this is something we can easily monitor and alert on in prometheus. Regards, Brian.