RBAC?

[Drugoy]

Hi. I've just read your article about using ssh certificates.

With ssh keys a user may access only the hosts that have his key added to the list of authorized keys (~/.ssh/authorized_keys) to some local account (and thus one needs not only to have a private key, but also to know correct login). The rest is restricted.

But how does such a restriction work with ssh certificates? Wouldn't the server, basically, let in ANY user with a correct certificate signed by a server-trusted CA?
In other words: how to configure server A to let in employees A and B, and configure server B to let in ONLY employee B?
That's quite a trivial thing to do with regular keys, but with ssh certificates - that's not so obvious (at least to me, after reading your article).

As far as I understood, implementing RBAC with ssh certificates on an enterprise needs to be done on the upper level, like on an SSO server (or right on the CA in case of direct PAM authentication [on CA] method mentioned in the article), is that correct?

[tashian]

Thanks @Drugoy for the question!
There's a couple answers to this.

• One answer is: Server B doesn't have an account on it for employee A, so employee A cannot access server B even with a trusted certificate.
• Another answer is to do it the way our commercial SSH Professional service does: Write PAM/NSS modules that do RBAC and user lifecycle management for you, with RBAC rules synced from a central server.
• Or, sign up for our commercial offering if you need remote RBAC policy management and don't want to roll this part on your own.

The role of the SSO server is just authentication, it's not an authorization server in this case, because authorization happens when the SSH connection is made. But, the SSO server can determine which principals are added to the SSH user certificate.

Hope this helps.

[Drugoy]

Thank you!