[26103] in Athena Bugs
Re: linux 9.3.12: ssh
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Thu Oct 7 11:40:08 2004
Date: Thu, 7 Oct 2004 11:37:39 -0400 (EDT)
Message-Id: <200410071537.i97FbdmI012159@brad-majors.mit.edu>
From: Garry Zacheiss <zacheiss@mit.edu>
To: Kevin Chen <kchen@mit.edu>
In-reply-to: "[26102] in Athena Bugs"
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
>> I just created a .k5login symlink and corresponding file in my homedir
>> with the contents:
>> kevin@CSAIL.MIT.EDU
This was your problem. If you create a .k5login file for a user
account, you effectively want it to contain your ATHENA.MIT.EDU null
instance principal in addition to any other principals you wish to
authorize. The existance of the .k5login overrides the default behavior
of allowing "username@DEFAULT.REALM" access to the local account
"username"; you must explicitly include your ATHENA principal if you
want to preserve that behavior.
In this case, the password auth behavior you were seeing was sshd
verifying that you knew the password for the principal
kchen@ATHENA.MIT.EDU, then consulting the .k5login file (via
krb5_kuserok()) and determining that even though you knew the password,
you were not authorized to log in.
Forwarding tickets from CSAIL to an Athena machine currently fails due
to a problem with sshd; you'll get logged in without tickets. This is
fixed in our sources and a fixed sshd is running on the dialups. It
will be fixed for private workstations in a forthcoming 9.3 patch
release.
You should recreate your .k5login file and make sure it contains:
kchen@ATHENA.MIT.EDU
kevin@CSAIL.MIT.EDU
and I think you'll find that password authentication will work
correctly.
Garry
