Your message dated Thu, 29 Jun 2006 11:00:21 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#345585: libpam-krb5: ssh error: 'ssh_gssapi_storecreds:
Not a GSSAPI mechanism' when using keyboard-interactive/pam
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: libpam-krb5
Version: 1.2.0-1
Severity: important
I began having this problem after upgrading from version 1.0-12 to
version 1.2.0-1. Downgrading to the original version fixes the problem.
The ssh client gives the following error message after typing the
password:
Read from remote host optimus: Connection reset by peer
Connection to optimus closed.
Here are what I believe to be the interesting lines from sshd's debuging
output (I think the line about ssh_gssapi_storecreds is the problem):
debug1: auth2_challenge_start: trying authentication method 'pam'
Postponed keyboard-interactive for cgallek from 192.168.0.14 port 51701
ssh2
debug2: PAM: sshpam_respond entering, 1 responses
Postponed keyboard-interactive/pam for cgallek from 192.168.0.14 port
51701 ssh2debug2: PAM: sshpam_respond entering, 0 responses
debug2: monitor_read: 60 used once, disabling now
Accepted keyboard-interactive/pam for cgallek from 192.168.0.14 port
51701 ssh2
debug1: monitor_child_preauth: cgallek has been authenticated by
privileged process
Accepted keyboard-interactive/pam for cgallek from 192.168.0.14 port
51701 ssh2
debug2: mac_init: found hmac-md5
debug2: mac_init: found hmac-md5
debug1: temporarily_use_uid: 1000/1000 (e=0/1000)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/1000
debug2: User child is on pid 3801
debug1: PAM: reinitializing credentials
debug1: do_cleanup
debug1: PAM: cleanup
Also note that this problem only occurs when authenticating the user via
the keyboard. It works just fine if you are forwarding credentials.
Thanks,
Craig
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.5
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libpam-krb5 depends on:
ii libc6 2.3.5-9 GNU C Library: Shared
libraries an
ii libcomerr2 1.38+1.39-WIP-2005.12.10-2 common error description
library
ii libkrb53 1.4.3-5 MIT Kerberos runtime
libraries
ii libpam0g 0.79-3 Pluggable Authentication
Modules l
libpam-krb5 recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1.2.0-3
Craig Gallek <[EMAIL PROTECTED]> writes:
> Thanks for following up on this. Version 1.2.0-3 is now working properly
> for me with the following sshd_config options:
> UsePAM yes
> ChallengeResponseAuthentication yes
> PasswordAuthentication no
Cool, thanks for checking! I'll go ahead and close this bug then.
> Just out of curiosity, do you have a pointer to a changelist that may
> have fixed this problem? I looked through the change logs and didn't
> see anything particularly relevant.
1.2.0-2 *should* have fixed the problem. The relevant changelog was:
* Always use a disk cache for temporary storage of credentials and cope
with not having module-specific data during pam_sm_setcred by passing
the cache path in an environment variable. This is required to cope
with OpenSSH's technique (when using ChallengeResponseAuthentication)
of doing PAM authentication in a child process and then opening the
session in the parent. (Closes: #339734)
If it didn't work in 1.2.0-2 but did work in 1.2.0-3, I'm not really sure
what could have fixed it. Possibly one of:
* Restructure the code to do user validation after obtaining their
initial tickets. This eliminates a lot of confusing special cases and
deferred checking and makes it easier to audit the code.
* Don't create the ticket cache until after successful authentication.
Otherwise, we leave files behind in /tmp.
but both should have just been cleanups.
I'm working on a new upstream 2.0 release now that will support most of
the additional functionality in the Red Hat version and will be cleaner
and more maintainable.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--- End Message ---
