[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#309439: marked as done (ssh-krb5: .k5login breaks password login)



Your message dated Thu, 28 Dec 2006 12:01:23 -0800
with message-id <8764bvzt64.fsf@windlord.stanford.edu>
and subject line Proper .k5login support now possible with libpam-krb5
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
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 [essigke@moe] 142 (~): ssh -vvv sftadm@moe, 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
sftadm@moe'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
sftadm@moe'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-interactive
Permission denied, please try again.

--/etc/ssh/sshd_config
...
PasswordAuthentication yes
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
...

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages ssh-krb5 depends on:
ii  adduser                     3.63         Add and remove users and groups
ii debconf 1.4.30.13 Debian configuration management sy ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcomerr2 1.37-2 common error description library
ii  libkrb53                    1.3.6-2      MIT Kerberos runtime libraries
ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l
ii  libssl0.9.7                 0.9.7e-3     SSL shared libraries
ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii  zlib1g                      1:1.2.2-4    compression library - runtime

-- debconf information:
  ssh/insecure_rshd:
  ssh/privsep_ask: true
  ssh/user_environment_tell:
* ssh/forward_warning:
  ssh/insecure_telnetd:
  ssh/new_config: true
* ssh/use_old_init_script: true
* ssh/SUID_client: true
* ssh/privsep_tell:
  ssh/ssh2_keys_merged:
* ssh/protocol2_only: true
  ssh/encrypted_host_key_but_no_keygen:
* ssh/run_sshd: true


--- End Message ---
--- Begin Message ---
The root cause of this bug is that regular PAM authentication derives the
principal from the local account using the default realm and therefore
only works properly if that's the correct Kerberos principal to use.
libpam-krb5 now supports a search_k5login option that provides the
behavior originally desired, and OpenSSH now always uses PAM for password
authentication.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

--- End Message ---

Reply to: