Sam Evans wrote:
-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.
Hundreds? Thats more then test user I was using, it only has about 50.
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.
See if you can run the sshd without using PAM. Either remove the pam_krb5 from the ppam.conf for SSH or set in the sshd_config UsePAM no.
It might be that the pam_krb5 was linked against a different version of the kerberos libs, and some how the two versions are getting combined.
Its an easy test and could rule out conflicts of libs.
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.
The problem I ran it to was with AFS, not OpenSSH. It was in the AFS RX protocol. OpenSSH has in packet.c: max_packet_size = 32768 by default, but looks like session.c can let the client set the size. But I don't see the OpenSSH client changing this.
Perhaps I will try the version of OpenSSH that's
currently in CVS.
Thanks for your help!
-Sam
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
