Douglas E. Engert
Wed, 21 Feb 2007 07:18:01 -0800
SOunds like a Solaris /etc/pam.conf configuration problem. You might need to add someththing like: # # sshd - Keyboard Interactive uses all PAM exits, but # On Solaris 10, password uses PAM, sshd-password # and keyboard interactives uses sshd-kdbint # # PAM session is called when GSSAPI delegation or # Kerberos password used, so get AFS token in all three cases. # We want a session type cache, so with ANL PAM # pass in ccache= to account routine # RedHat PAM uses session caches already # # Can allow radius, krb5 or local passwords. # RADIUS should only use kbdint, as it may send challenge. # # Used if PAMAuthenticationViaKBDInt yes sshd-kbdint auth requisite pam_authtok_get.so.1 sshd-kbdint auth required pam_dhkeys.so.1 sshd-kbdint auth required pam_unix_cred.so.1 #sshd-kbdint auth sufficient /krb5/lib/pam_radius_auth.so.1 use_first_pass sshd-kbdint auth sufficient pam_krb5.so.1 #sshd-kbdint auth required pam_unix_auth.so.1 sshd-kdbint account requisite pam_roles.so.1 sshd-kdbint account required pam_unix_account.so.1 sshd-kdbint account required /krb5/lib/pam_krb5_ccache.so.1 ccache=/tmp/krb5 cc_%u_%p sshd-kdbint session required pam_unix_session.so.1 sshd-kdbint session required /krb5/lib/pam_afs2.so.1 # Used if PasswordAutheitication yes is set: sshd-password auth requisite pam_authtok_get.so.1 sshd-password auth required pam_dhkeys.so.1 sshd-password auth required pam_unix_cred.so.1 ##sshd-password auth sufficient /krb5/lib/pam_radius_auth.so.1 use_first_pas s sshd-password auth sufficient pam_krb5.so.1 # allows login with local password #sshd-password auth required pam_unix_auth.so.1 sshd-password account requisite pam_roles.so.1 sshd-password account required pam_unix_account.so.1 sshd-password account required /krb5/lib/pam_krb5_ccache.so.1 ccache=/tmp/ krb5cc_%u_%p sshd-password session required pam_unix_session.so.1 sshd-password session required /krb5/lib/pam_afs2.so.1 # Used by GSS, but ssh has bug about saving creds, so we use session based creds . sshd-gssapi account requisite pam_roles.so.1 sshd-gssapi account required pam_unix_account.so.1 sshd-gssapi account required /krb5/lib/pam_krb5_ccache.so.1 ccache=/tmp/krb 5cc_%u_%p sshd-gssapi session required pam_unix_session.so.1 sshd-gssapi session required /krb5/lib/pam_afs2.so.1 sshd-gssapi session required /krb5/lib/pam_krb5_ccache.so.1 clean Kent Nasveschuk wrote:
Hello, I don't know if this is a Heimdal problem with Solaris or just Solaris 10 in general. I have a Heimdal KDC 0.7.2 using OpenLDAP backend 2.3.32 running on Red Hat 4/U4. Clients are RedHat 3.0 u5/6/7/8 and 4.0 u4. They are all using an updated sshd daemon OpenSSH4.5p1. These all work fine with logins, and delegate credentials so that I can ssh box to box without supplying a password. The Solaris boxes use stock Sun sshd and gssapi/kerberos components.From a Solaris 10 to any Red Hat box I get the same results. I can sshto a Solaris box supply a password and gain access, klist lists principal ticket,shows flags and encryption type. If I try to ssh to another Solaris box, I get a password prompt. Also, if I ssh to a Solaris box from any Red Hat box, I get a password prompt. from the client: debug1: Calling gss_init_sec_context debug1: ssh_gssapi_init_ctx(809f0d0, sol101cts, 1, 0, 8047ae0) debug1: Delegating GSS-API credentials debug3: ssh_gssapi_import_name: snprintf() returned 14, expected 15 debug1: Remote: Negotiated main locale: C debug1: Remote: Negotiated messages locale: C debug1: Received KEXGSS_HOSTKEY debug1: Received GSSAPI_COMPLETE debug1: Calling gss_init_sec_context debug1: ssh_gssapi_init_ctx(809f0d0, sol101cts, 1, 8047ad8, 8047ae0) debug1: Delegating GSS-API credentials debug1: bits set: 525/1024 debug3: check_host_in_hostfile: filename /home/smitha/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug3: check_host_in_hostfile: filename /home/smitha/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host 'sol101cts' is known and matches the advertised RSA hostkey. debug1: Found key in /home/smitha/.ssh/known_hosts:2 debug2: kex_derive_keys debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0 debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug2: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug3: start over, passed a different list gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug2: Authenticating with GSS-API context from key exchange (w/ MIC) debug2: we sent a gssapi-keyex packet, wait for reply debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: ssh_gssapi_init_ctx(809f0d0, sol101cts, 0, 0, 8047aa0) debug3: ssh_gssapi_import_name: snprintf() returned 14, expected 15 debug2: we sent a gssapi-with-mic packet, wait for reply debug1: ssh_gssapi_init_ctx(80fb878, sol101cts, 1, 0, 8047b00) debug1: Delegating GSS-API credentials debug3: ssh_gssapi_import_name: snprintf() returned 14, expected 15 debug1: ssh_gssapi_init_ctx(80fb878, sol101cts, 1, 8047ae8, 8047af0) debug1: Delegating GSS-API credentials debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug2: we did not send a packet, disable method On the server side: Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug1: userauth-request for user smitha service ssh-connection method gssapi-keyex Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug1: attempt 1 initial attempt 0 failures 1 initial failures 0 Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: input_userauth_request: try method gssapi-keyex Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: Mapping initiator GSS-API principal to local username Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: Mapped the initiator to: smitha Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: Starting PAM service sshd-gssapi for method gssapi-keyex Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug3: Trying to reverse map address 10.11.99.94. Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.info] Failed gssapi-keyex for smitha from 10.11.99.94 port 32820 ssh2 Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug1: userauth-request for user smitha service ssh-connection method gssapi-with-mic Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug1: attempt 2 initial attempt 0 failures 2 initial failures 0 Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: input_userauth_request: try method gssapi-with-mic Feb 21 07:07:32 sol101cts sshd[2056]: [ID 800047 auth.debug] debug1: Client offered gssapi userauth with { 1 2 840 113554 1 2 2 } (supported) Feb 21 07:07:34 sol101cts sshd[2056]: [ID 800047 auth.debug] debug1: Received delegated GSS credentials Feb 21 07:07:34 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: Mapping initiator GSS-API principal to local username Feb 21 07:07:34 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: Mapped the initiator to: smitha Feb 21 07:07:34 sol101cts sshd[2056]: [ID 800047 auth.debug] debug2: Starting PAM service sshd-gssapi for method gssapi-with-mic Feb 21 07:07:35 sol101cts sshd[2056]: [ID 800047 auth.notice] Failed gssapi-with-mic for smitha from 10.11.99.94 port 32820 ssh2 It seams like Solaris is not accepting delegated credentials. I've gone round and round looking for an answer. Any suggestions would be appreciated. Kent N
-- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444