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 thisby 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.
All,you mistype your wiki password or your webmail password, you don't magically gain SSH access to All The Things?
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
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 thisby 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.
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.
On 5/31/22 12:05, Dan Mahoney wrote:
On most of our boxes, ssh is the ONLY kerberized app, but there's noprovision 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 someclients, 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
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 configuredto
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 auser
by means of the user's .k5login file.
Please, no - set up a localname mapping instead of trying to manage a bajilion k5login files.
On Tue, May 31, 2022 at 3:36 PM Carson Gaspar <carson@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
On May 31, 2022, at 3:35 PM, Carson Gaspar <carson@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).
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.)
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 thisby 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 49:14:34 |
| Calls: | 6,648 |
| Files: | 12,200 |
| Messages: | 5,330,097 |