Bug#309439: ssh-krb5: .k5login breaks password login

[Russ Allbery]

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]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309439: ssh-krb5: .k5login breaks password login

[Sam Hartman]

Are you using pam_krb5 for password logins?

If so, pam_krb5 also respects .k5login, so it is a feature not a bug.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309439: ssh-krb5: .k5login breaks password login

[Timm Essigke]

Dear Russ,
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.
Timm
Russ Allbery wrote:

With the stock Kerberos v5 libraries, the last that I checked (which
admittedly was some time ago), various things interact so that password
authentication is only checked against the first listed principal in
.k5login.  Could you try putting your principal first in that file and see
if that resolves the problem?  (I'm not sure if that's subsequently been
fixed in K5, but if not, it would explain this.)

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309439: ssh-krb5: .k5login breaks password login

[Russ Allbery]

Timm Essigke <[EMAIL PROTECTED]> writes:

> Package: ssh-krb5
> Version: 3.8.1p1-7
> Severity: normal

> Password login fails, if .k5login is present. If it .k5login is renamed,
> it works again (I made sure that the file is world readable).  I would
> like certain users to access the account via .k5login, but have a
> password login for myself also from non-kerberized hosts (laptop).

> In the following examples I run [EMAIL PROTECTED] 142 (~): ssh -vvv
> [EMAIL PROTECTED], but same is true for remote logins.

> Sorry for the lengthy report, but I am not sure if it is a configuration
> mistake or a bug...

With the stock Kerberos v5 libraries, the last that I checked (which
admittedly was some time ago), various things interact so that password
authentication is only checked against the first listed principal in
.k5login.  Could you try putting your principal first in that file and see
if that resolves the problem?  (I'm not sure if that's subsequently been
fixed in K5, but if not, it would explain this.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309439: ssh-krb5: .k5login breaks password login

[Timm Essigke]

Package: ssh-krb5
Version: 3.8.1p1-7
Severity: normal
Password login fails, if .k5login is present. If it .k5login is renamed, 
it works again (I made sure that the file is world readable).
I would like certain users to access the account via .k5login, but have 
a password login for myself also from non-kerberized hosts (laptop).

In the following examples I run [EMAIL PROTECTED] 142 (~): ssh -vvv 
[EMAIL PROTECTED], but same is true for remote logins.

Sorry for the lengthy report, but I am not sure if it is a configuration 
mistake or a bug...

Thanks in advance,
Timm
Without .k5login I can login by password (with or without kerberos ticket):
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[EMAIL PROTECTED]'s password:
debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.


With valid kerberos ticket and .k5login I can login:
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug3: start over, passed a different list 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug3: preferred 
gssapi-with-mic,gssapi,publickey,keyboard-interactive,passworddebug3: 
authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentication succeeded (gssapi-with-mic).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.


After kdestroy, login fails:
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug3: start over, passed a different list 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug3: preferred 
gssapi-with-mic,gssapi,publickey,keyboard-interactive,passworddebug3: 
authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Miscellaneous failure
No credentials cache found

debug1: Trying to start again
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi
debug1: Next authentication method: gssapi
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/essigke/.ssh/identity
debug3: no such identity: /home/essigke/.ssh/identity
debug1: Offering public key: /home/essigke/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug1: Offering public key: /home/essigke/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[EMAIL PROTECTED]'s password:
debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: 
gssapi-with-mic,publickey,gssapi,password,keyboard-interac