openssh is configured to use PAM and sshd_config has "UsePam" set to "yes" pam.conf has something like this (We're using the "other" stack): # grep ^other /etc/pam.conf other auth requisite pam_authtok_get.so.1 debug other auth sufficient pam_krb5.so.1 use_first_pass debug other auth required pam_unix_auth.so.1 use_first_pass debug other account required pam_krb5.so.1 debug other account optional pam_unix_account.so.1 debug other session required pam_krb5.so.1 debug other session optional pam_unix_session.so.1 debug other password required pam_krb5.so.1 debug Now, If I log in via ssh as a user who has a Kerberos principal, everything works just fine. If a local account is used, sshd segfaults. If I remove the pam_krb5.so.1 reference auth line, the local user can successfully authenticate. Also, KerberosAuthentication and KerberosOrLocalPasswd are both "yes" (in the sshd_config). This gets me an sshd crash in the circumstances described. Setting KerberosAuthentication to "no" gets me a core file Setting KerberosOrLocalPasswd to "no" does *not* cause sshd to crash, but the user in question cannot authenticate at all. Setting both to "no" behaves the same way as setting only KerberosAuthentication to "no" (core file). The back trace below is the same if I'm running it on a "live" sshd or on a core file. #0 0xfec1d654 in profile_get_value () from /usr/lib/gss/do/mech_krb5.so.1 #1 0xfec1dda0 in profile_get_options_boolean () from /usr/lib/gss/do/mech_krb5.so.1 #2 0xfeca3b4c in attempt_krb5_login () from /usr/lib/security/pam_krb5.so.1 #3 0xfeca3558 in pam_sm_authenticate () from /usr/lib/security/pam_krb5.so.1 #4 0xff373060 in run_stack () from /home/jd/../../lib/libpam.so.1 #5 0xff3732e8 in pam_authenticate () from /home/jd/../../lib/libpam.so.1 #6 0x7e900 in sshpam_auth_passwd () #7 0x4c6c0 in auth_password () #8 0x6bb84 in mm_answer_authpassword () #9 0x6acb4 in monitor_read () #10 0x6a574 in monitor_child_preauth () #11 0x45e70 in demote_sensitive_data () #12 0x4a1b8 in main ()
Created attachment 970 [details] sshd -ddde output when failure occurs From Darren Tucker: From the sshd debug trace, the order of what happens is: 1) ssh "none" auth attempt: fails 2) gssapi-with-mic auth atempt (several?): fails 3) publickey auth attempt (several): fails 4) keyboard-interactive auth attempt: crashes
Created attachment 974 [details] sshd -ddde with "ssh" using keyboard-interactive only Debug output of the failure with the client using keyboard-interactive auth only
Created attachment 975 [details] sshd -ddde with "ssh" using gssapi-with-mic,publickey,password
Created attachment 976 [details] sshd -ddde with "ssh" using password only Failure using password authentication only. "Segmentation Fault" line not captured, but it was there. jd
Which compiler and build options are you using? Which options are active in sshd_config? There seems to be some stuff missing from the debug output. For example, there's lines like: "debug3: entering", which should have a function name in the middle. Is that how they appear on the screen? And this one is a wild guess: do you have "PermitEmptyPasswords" set to "yes" and does the behaviour change if it's set to "no"?
Created attachment 978 [details] sshd_config for in effect when failure occurs (In reply to comment #5) > Which compiler and build options are you using? SUNWspro C compiler, version 4.2 (patch 1). Only using "-g" and generic libs and default linker directives. >Which options are active in sshd_config? See attached sshd_config. The configure patameters are: > ./configure --prefix=/opt/openssh --localstatedir=/etc/opt/openssh > - --sysconfdir=/etc/opt/openssh --with-kerberos5=../.. --with-zlib=../.. > - --with-ssl-dir=../.. --disable-wtmp --disable-utmp > - --with-random=/dev/random --with-pam --with-ldflags=-ldl > There seems to be some stuff missing from the debug output. For example, > there's lines like: "debug3: entering", which should have a function name in > the middle. Is that how they appear on the screen? Yes > And this one is a wild guess: do you have "PermitEmptyPasswords" set to "yes" > and does the behaviour change if it's set to "no"? It's set to "no" already. (In reply to comment #5) > Which compiler and build options are you using? Which options are active in > sshd_config? > There seems to be some stuff missing from the debug output. For example, > there's lines like: "debug3: entering", which should have a function name in > the middle. Is that how they appear on the screen? > And this one is a wild guess: do you have "PermitEmptyPasswords" set to "yes" > and does the behaviour change if it's set to "no"?
Compiling without Kerberos libs (omitting --with-kerberos) yields an sshd binary that does NOT crash.
(In reply to comment #7) > Compiling without Kerberos libs (omitting --with-kerberos) yields an sshd > binary that does NOT crash. OK then my guess is it's one of 2 things: 1) There's a block of code in auth-krb5.c that stores the Kerberos Credential Cache where PAM can find it ("do_pam_putenv("KRB5CCNAME", authctxt->krb5_ccname);"). Perhaps this is confusing the PAM modules (but it should only be done on a successful krb authentication). You can try commenting it out. 2) You're linking sshd with self-built MIT krb5 but the PAM modules are built against Solaris' native kerberos and these binary compatible.
(In reply to comment #6) > > There seems to be some stuff missing from the debug output. For example, > > there's lines like: "debug3: entering", which should have a function name in > > the middle. Is that how they appear on the screen? > > Yes OK this at least is solved: the missing names are supplied by the __func__ macro. It would appear that your compiler doesn't support it (or needs a flag to enable it or something).
(In reply to comment #8) > and these [are not] binary compatible. This is supposition on my part, BTW. I'm not sure what's supposed to happen when name clashes occur between an app and PAM modules or other libraries that they dlopen (but I would have bet on the answer being "nothing good"). It would seem that if this is indeed the cause of the problem then you could a) remove the pam_krb5 modules from the stack and rely on sshd's built-in support or b) build openssh with the Solaris native krb5 libraries (I've not tried this).
(In reply to comment #10) > (In reply to comment #8) > a) remove the pam_krb5 modules from the stack and rely on sshd's built-in > support or b) build openssh with the Solaris native krb5 libraries (I've not > tried this). Alas, Solaris provides no native client krb5 libraries (just kadm and the mech_krb5 libs, which are missing a handful of functions) I've recompiled with gcc and the __func__ messages all work much better. I might drop in my own pam_krb5 (compiled with MIT libs) and see if that fares any better. jd
Hi, did changing the krb5 libraries help?
three months and no reply == no bug
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.