Using an alternate principal for ssh

[Dan Mahoney]

All,

In the dayjob, many apps default to the kerberos principal, and we'd like to make ssh (whether used with kinit and gssapi auth, or with a typed-password, via KerberosAuthentication, or PAM) use a different principal, say user/ssh@REALM, such that if you mistype your wiki password or your webmail password, you don't magically gain SSH access to All The Things?

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.

-Dan

[Greg Hudson]

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().

[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

> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

[Carson Gaspar]

On 5/31/2022 9:05 AM, Dan Mahoney wrote:
> All,
>
> In the dayjob, many apps default to the kerberos principal, and we'd like to make ssh (whether used with kinit and gssapi auth, or with a typed-password, via KerberosAuthentication, or PAM) use a different principal, say user/ssh@REALM, such that if you mistype your wiki password or your webmail password, you don't magically gain SSH access to All The Things?
>

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

Looking at pam_krb5, if you log in as user/ssh@REALM, it will use that
principal and change the PAM user to the results of the krb5 localname
mapping. You'd have to configure the localname mapping in krb5.conf (or
an alternate config fragment just for sshd and set KRB5_CONFIG), and
configure ssh to only allow users of the form */ssh@REALM to prevent
users from logging in as just themselves. I haven't tested this, and I
don't know if sshd will get grumpy if the PAM stack changes the user name.

The alternative would be to patch pam_krb5 to support a user_instance
config option as well as user_realm. It would be a fairly small change,
and I suspect Russ might approve it to go upstream.

I don't know how hard it would be to support changing the user name
inside a match block in sshd_config (or if the maintainers would
consider accepting such a PR), but that would be the other option I'd
investigate.

--

Carson

[Carson Gaspar]

On 5/31/2022 12:16 PM, Jeffrey Hutzelman wrote:
> 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.

I agree about the sshd config options, but looking at the source code
for Russ's pam_krb5, I don't think it will work as-is without changing
the username provided by the client (see my previous post).

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

Please, no - set up a localname mapping instead of trying to manage a
bajilion k5login files. I was so happy when MIT finally added the
k5login_directory option so I could move .k5login out of the home dir
and stop users from doing terrible things.

--

Carson

[Jeffrey Hutzelman]

On Tue, May 31, 2022 at 3:36 PM Carson Gaspar <car...@taltos.org> wrote:

> On 5/31/2022 12:16 PM, Jeffrey Hutzelman wrote:
> > 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.
>
> I agree about the sshd config options, but looking at the source code
> for Russ's pam_krb5, I don't think it will work as-is without changing
> the username provided by the client (see my previous post).
>

It will. You want something like
alt_auth_map=%s/ssh@REALM
only_alt_auth=true

> > 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.
>
> Please, no - set up a localname mapping instead of trying to manage a
> bajilion k5login files.

Yeah, a mapping is probably better for this application.

[Dan Mahoney]

> On May 31, 2022, at 3:35 PM, Carson Gaspar <car...@taltos.org> wrote:
>
> On 5/31/2022 12:16 PM, Jeffrey Hutzelman wrote:
>> 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.
>
> I agree about the sshd config options, but looking at the source code for Russ's pam_krb5, I don't think it will work as-is without changing the username provided by the client (see my previous post).

I had missed Russ' pam_krb5. I had looked at the stock FreeBSD one and the redhat one, which lack those options. This warrants building some VM's to mess around with.

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

> Please, no - set up a localname mapping instead of trying to manage a bajilion k5login files. I was so happy when MIT finally added the k5login_directory option so I could move .k5login out of the home dir and stop users from doing terrible things.

Our userbase is pretty small and systems are overall managed with puppet, so that's not a problem for us. We'd need to either disallow GSSAPI entirely, or accept that we need to manipulate a dir of k5login files outside the users' homedirs.

I'll take a directory of k5login files. As an organization we don't like pubkey auth because there's no easy central control over users. (i.e. pubkey completely sidesteps kerberos. If you have something like ldap deployed, that can help, but we don't like the idea of every system call like ls -al phoning an LDAP server.)

-Dan

[Carson Gaspar]

On 5/31/2022 12:43 PM, Jeffrey Hutzelman wrote:
>
> On Tue, May 31, 2022 at 3:36 PM Carson Gaspar <car...@taltos.org> wrote:
>

> I agree about the sshd config options, but looking at the source code
> for Russ's pam_krb5, I don't think it will work as-is without
> changing
> the username provided by the client (see my previous post).
>
>

> It will. You want something like
> alt_auth_map=%s/ssh@REALM
> only_alt_auth=true

Ah - I missed that as it takes a different code path that bypasses the
normal user name mapping. Thanks for the correction!

--

Carson

[Russ Allbery]

Dan Mahoney <da...@prime.gushi.org> writes:

> Our userbase is pretty small and systems are overall managed with
> puppet, so that's not a problem for us. We'd need to either disallow
> GSSAPI entirely, or accept that we need to manipulate a dir of k5login
> files outside the users' homedirs.

If you're already willing to manage .k5login files, the search_k5login
option to my PAM module may also work and the whole reason why I started
contributing to that module instead of using Red Hat's (to solve an old
issue that Stanford had).

alt_auth_map is the more precise solution, but it only allows a single
mapping, whereas with search_k5login you can do whatever you want as long
as you populate .k5login accordingly.

> I'll take a directory of k5login files. As an organization we don't
> like pubkey auth because there's no easy central control over users.
> (i.e. pubkey completely sidesteps kerberos. If you have something like
> ldap deployed, that can help, but we don't like the idea of every system
> call like ls -al phoning an LDAP server.)

Yes, at Stanford we disabled public key and required GSS-API for most
things.

--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>

[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...@mit.edu> on behalf of Greg Hudson <ghu...@mit.edu>
Sent: Tuesday, May 31, 2022 3:08 PM
To: Dan Mahoney <da...@prime.gushi.org>; kerb...@mit.edu <kerb...@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.