SSH certificates - restricting to host groups

[Michael Ströder]

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.