Should auth_krb4_password read .klogin ?

[Booker C. Bense]

On Wed, 28 Nov 2001, John Hawkinson wrote:

> Booker C. Bense <bbense at networking.stanford.edu> wrote on Wed, 28 Nov 2001
> at 13:11:12 -0800 in <Pine.GSO.4.33.0111281257190.10686-100000 at shred.stanford.edu>:
>
>
> > - One of Stanford's local oddities in it's kerberos deployment
> > is that it supports using the password of a principal in the
> > .klogin file to access an account.
> ...
> > - I'll be hacking this behaviour into a local version of ssh, but
> > is there any interest in having these patches? The flag file
> > is ugly, but perhaps it could be changed to an config option.
>
> I don't think this is a good idea at all.
>
>
> But perhaps I'm overreacting to changes to a familiar system and the
> changes would not be so disturbing. But I fear they'd have their own
> bizarro security problems N years down the line that don't justify
> their existance now, given the limitted appeal.
>

- You're misunderstanding what I'm offering. IMHO, it's a misfeature
of openssh to ignore the .klogin entries when accepting kerberos
logins via password. No other kerberos software does this.
It's a useful hack to do this on systems that support AFS, but
IMHO it should not be the default behaviour. Suppose I had the
principal root at MY.DOMAIN, if ssh allowed root kerberos logins
I would now have root access on all the machines in the domain.

- This doesn't work in the current code, but for any local acct
that has a non-zero uid it does.

- I agree that reading .klogin for alternative login principals
is wierd, but it's entrenched here and I have to support it.
It's kind of consistant in that if you use a service tkt to
login instead of a password you get the same behaviour.
However, I am not offering those patches.

- As far as contributing our local wierdnesses to MIT's k5 code,
I have done quite a bit of that, but some things they just refuse
to swallow. %-).

- Booker C. Bense