Timm Essigke <[EMAIL PROTECTED]> writes: > thanks a lot!
> If I put [EMAIL PROTECTED] first in .k5login it works with password > authentication. > Nice workaround! Or isn't it a bug but a feature!? > What I would expect is that it takes the principal given as user for ssh > and doesn't touch .k5login if Kerberos authentication fails... > Anyway the problem seems not to be the package, but upstream. Well, the way that this is supposed to work from a Kerberos perspective is that the .k5login file represents a mapping from Kerberos principals to local usernames. So when the .k5login file is present, Kerberos should not make the assumption that the username corresponds to the principal by the same name in the default local realm, and instead should verify the principal used to access the account against the membership of the .k5login file. This is a very important feature that some sites rely on, since they have local users that conflict with principal names in their local realms that should not be accessible to the user that has that principal. The ideal behavior from the Kerberos perspective would be to have the user be able to both specify the account they're logging on to and the Kerberos principal that they're going to use for password authentication, since they can be different. There's no good way to support that, though. Failing that, what *I'd* actually expect (and what we've patched Kerberos to do locally at Stanford) is for the provided password to be checked against every principal listed in .k5login, which would result in .k5login being used the same way for both password login and for verification of native Kerberos login via ssh-krb5, klogind, etc. I need to separate out those patches and try to sell the Kerberos maintainers on the idea. That would really not give you the semantics that you want, though, if you want to restrict password logins to only one particular account but allow many other accounts to access the server via Kerberos login. You're currently relying on something of an odd corner case, arguably a bug, in the way that .k5login checking works in combination with a username/password login. I would be a bit leery of relying on that behavior (of only checking the first line of .k5login) to remain unchanged in the future. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
