[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Solaris 10 delegated credentials fails sshd w/Heimdal KDC

To: Kent Nasveschuk <Kent.Nasveschuk@fastsearch.com>
Subject: Re: Solaris 10 delegated credentials fails sshd w/Heimdal KDC
From: "Douglas E. Engert" <deengert@anl.gov>
Date: Wed, 21 Feb 2007 08:55:52 -0600
Cc: Heimdal discuss <heimdal-discuss@sics.se>
In-Reply-To: <1172060610.15557.28.camel@kln1.bos3.fastsearch.net>
References: <1172060610.15557.28.camel@kln1.bos3.fastsearch.net>
Sender: owner-heimdal-discuss@sics.se
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
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  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
References:
- Solaris 10 delegated credentials fails sshd w/Heimdal KDC
  - From: Kent Nasveschuk <Kent.Nasveschuk@fastsearch.com>
Prev by Date: 新着メッセージ
Next by Date: proprietary
Prev by thread: Solaris 10 delegated credentials fails sshd w/Heimdal KDC
Next by thread: proprietary
Index(es):
- Date
- Thread