Clarify interaction with sudoers file

[asteele4]

This is request to fill what seems to be a gap in the docoumentation around how pam-ussh hooks into the sudoers file (or its includes).

I have just started investigating ssh certs and setup a simple test environment to learn how this works.

I was pleased it only took a couple of hours to have my test server authenticating with certs working so known_hosts messages no longer appear and authorized_keys are not needed.

The next step was to integrate pam-ussh into the solution but can't get it to work.

It appears pam-ussh is accepting the certificate I'm presenting it with.

My confusion is how this hooks into my sudo rules.

I assume when the CA signs the public key, it gives the user key a number of principals: the user's name and the roles that user has, let say one is "allowed_root".
That "allowed_root" would be listed in /etc/ssh/root_authorized_principals.
But what should the sudoers file contain? Something like:
allowed_root ALL =(ALL) ALL
I'm having trouble seeing how the pam-ussh hooks into the sudoers rules.
Could the documentation fill out this final missing piece of the puzzle.

[bcg62]

Im not sure it ties together this easily.

Even though you have a ssh cert, singed by a CA which a destination machine may be configured to trust, if your linux user account does not exist on the machine you wont be able to login (granted I think there may be other pam modules to create accounts in this situation on the fly).

Additionally, along with your linux account is your linux group configuration, these are the groups sudo references. Is is not aware of your ssh cert principals. when running a sudo command, sudo offloads authentication to pam which has your ssh CA config. which is more or less pass/fail based on conditions.

In my experience i've seen IDM/IDP/LDAP/kerberos systems bridge this gap where linux user accounts, groups, and sudo config are deployed across an org from central tooling and the CA just for auth/creds.

there are products like https://goteleport.com/ which do alot of this out of the box.

[asteele4]

Thanks @bcg62 for the response.

But it's left me more confused. I knew of the LDAP/IDM solutions, for complicated non-technical reasons I have limited ability to use them - why I was investigating pam-ussh.

The users and groups I'm already using to control sudo privileges.

Given what you've said, I'll turn my question around: what "value add" does pam-ussh provide over users and groups? If I have a user I'm already granting access to the host and sudo abilities (via either their username or group), what benefit do I get from using pam-ussh?

The use I'd expected was I was thinking I could make use of two additional benefits ssh certificates provides: validity window and principals.

For example, I was hoping I could have a sudo rule that said a principle (like "allowed_root") could become root. Then I could have a permanent sudo rule (like I mentioned above) and when someone needs sudo access during a change window, we'd sign their key giving the certificate both the principal and a validity of the change window. Thus permitting them sudo access only for the duration of their change and without any updates to /etc/sudoers.

If that's not the expected use case, if a user is already granted access to a host, what additional benefit do I get from using pam-ussh to authorise sudo permissions?

[apologies for taking so long to reply, I forgot to turn on notifications for the thread]

[pmoody-]

For example, I was hoping I could have a sudo rule that said a principle (like "allowed_root") could become root.

it's been a while since i've used pam-ussh in production, but I would suggest implementing this with a sudoers rule of

%allowed_root ALL=(ALL:ALL) ALL

and then putting your user(s) in the allowed_root group.

the confusion might arise from an assumption that pam-ussh reads /etc/ssh/sshd_config and parses things like authorized principals files. it doesn't

Given what you've said, I'll turn my question around: what "value add" does pam-ussh provide over users and groups? If I have a user I'm already granting access to the host and sudo abilities (via either their username or group), what benefit do I get from using pam-ussh?

sshd only checks certificate validity when a user authenticates to a host. if you're expiring ssh user certificates (and if you're using certificates for user authentication, you are making them expire right?), it's quite possible that you will have users running on hosts long after their authentication credentials expired. pam-ussh allowed me to ensure that anyone trying to run a privileged command had recently authenticated.