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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
