-SNIP- > > Do you have any more of the sshd trace? > I do. Here is the trace from start to finish (using sshd -ddd):
-- START -- debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=testuser devs= debug1: kbdint_alloc: devices 'pam' debug2: auth2_challenge_start: devices pam debug2: kbdint_next_device: devices <empty> debug1: auth2_challenge_start: trying authentication method 'pam' debug3: mm_sshpam_init_ctx debug3: mm_request_send entering: type 46 debug3: monitor_read: checking request 46 debug3: mm_answer_pam_init_ctx debug3: mm_request_send entering: type 47 debug3: mm_request_receive entering debug3: mm_sshpam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX debug3: mm_request_receive_expect entering: type 47 debug3: mm_request_receive entering debug3: mm_sshpam_init_ctx: pam_init_ctx failed Failed keyboard-interactive for testuser from 10.104.40.162 port 33336 ssh2 debug1: userauth-request for user testuser service ssh-connection method password debug1: attempt 5 failures 5 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: monitor_read: checking request 10 debug1: temporarily_use_uid: 500/500 (e=0/0) debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug1: restore_uid: 0/0 debug1: Kerberos password authentication failed: ASN.1 encoding ended unexpectedly debug1: krb5_cleanup_proc called debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 debug3: mm_auth_password: user not authenticated Failed password for testuser from 10.104.40.162 port 33336 ssh2 Failed password for testuser from 10.104.40.162 port 33336 ssh2 debug3: mm_request_receive entering Connection closed by 10.104.40.162 debug1: Calling cleanup 0x806d410(0x0) debug1: Calling cleanup 0x8060f88(0x8090c50) debug1: krb5_cleanup_proc called -- END -- > > Sounds like a big ticket problem. We have seen problems with AFS > (which has been reported and fixed in the CVS) when the ticket is big. > > I have not seen this, and just did a test with my 2003 AD user which > is in too many groups. It worked fine with OpenSSH-3.9p1 with MIT krb5-1.4 > running on Solaris. But maybe my test user is not in enough groups to cause > this problem. > I think this is exactly what is happening. We have some users who are members of hundreds of groups (don't ask me why, long overdrawn story) which is likely causing the problem. > The OpenSSH may be finding an older krb5 shared library, that has problems. > Does it also have PAM? Is the pam_krb5 loading an old Kerberos? > > Does "ldd sshd" show that all new krb5 libs are being used? Yes, it is pointing to the MIT Kerberos v1.4 library, so all should be good there. > > If you run Ethereal, how big is the bad ticket vs the good ticket. > The bad ticket appears about about ~70 bytes larger than the working one. With an additional 2 continuation packets as compared to the 1 continuation for the working ticket. I think it is likely the same issue that you ran into with large ticket sizes. Perhaps I will try the version of OpenSSH that's currently in CVS. Thanks for your help! -Sam ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
