Using an alternate principal for ssh

[Jeffrey Hutzelman]

That code should not actually used on a properly-configured PAM-based
system. Typical configuration for such systems should enable UsePAM and
KbdInteractiveAuthentication and disable PasswordAuthentication and
ChallengeResponseAuthentication. This causes all password verification to
go through PAM. Then all you need is a PAM module that can be configured to
behave as you desire. I believe Russ Allbery's pam_krb5 has all the knobs
you need.

For true Kerberos authentication (i.e. using Kerberos tickets, not a
password), you can control which principals are allowed to log in as a user
by means of the user's .k5login file.

-- Jeff

On Tue, May 31, 2022 at 3:10 PM Greg Hudson <ghudson at mit.edu> wrote:

> 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
>