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 ssh
to 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
