Kerberos uses a plugin to determine which principal is used in a given situation. You could write a plugin that forces the principal to user/ssh if the service is ssh. The API isn't complex. There are several examples.
You'd write the code to check if the service is ssh. If so, you'd look for a cache collection with user/ssh (there's an API call to do that). If so, return that cache collection. If not return authoritative not found. If it's not ssh, return the code that causes it to defer to other plugins. ________________________________ From: Kerberos <kerberos-boun...@mit.edu> on behalf of Greg Hudson <ghud...@mit.edu> Sent: Tuesday, May 31, 2022 3:08 PM To: Dan Mahoney <d...@prime.gushi.org>; kerberos@mit.edu <kerberos@mit.edu> Subject: Re: Using an alternate principal for ssh On 5/31/22 12:05, Dan Mahoney wrote: > On most of our boxes, ssh is the ONLY kerberized app, but there's no > provision in krb5.conf to say what the default principal based on a username > is. None of the PAM modules seem to be able to set it, either. I conjured > up an elaborate way to do this by forcing the .k5logindir to be something the > users couldn't touch, and forcing a create for each user, but this doesn't > help the password case. > > Does anyone know of a simple way to accomplish this? There are some clients, > like mobile ones, where, VPN or no, kinit'ing is not an option. The OpenSSH sshd code decides the principal name, not libkrb5. Looking at the OpenSSH auth-krb5.c, I don't think there's any configurability; it picks a principal name of authctxt->pw->pw_name (except on AIX), parses that, and calls krb5_get_init_creds_password(). ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
