on behalf of Greg Hudson
Sent: Tuesday, May 31, 2022 3:08 PM
To: Dan Mahoney ; 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 w
Dan Mahoney 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
On 5/31/2022 12:43 PM, Jeffrey Hutzelman wrote:
On Tue, May 31, 2022 at 3:36 PM Carson Gaspar 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
> On May 31, 2022, at 3:35 PM, Carson Gaspar 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 disabl
On Tue, May 31, 2022 at 3:36 PM Carson Gaspar 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
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 c
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
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.
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 thi
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 w
10 matches
Mail list logo
