Using an alternate principal for ssh

[Charles Hedrick]

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-bounces at mit.edu> on behalf of Greg Hudson <ghudson at mit.edu>
Sent: Tuesday, May 31, 2022 3:08 PM
To: Dan Mahoney <danm at prime.gushi.org>; kerberos at mit.edu <kerberos at 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 at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos