Kerberos MIT SSH Solaris 9
Douglas E. Engert
deengert at anl.gov
Mon Feb 11 12:41:13 EST 2008
Do you need a ~/.k5login file to allow the principal to use the local account?
debug2: Mapping initiator GSS-API principal to local username
debug2: Mapped the initiator to: icm
debug2: Starting PAM service sshd-gssapi for method gssapi-keyex
Are the forward and reverse DNS (or /etc/hosts) mappings OK?
debug3: Trying to reverse map address 11.10.243.5.
Failed gssapi-keyex for icm from 11.10.243.5 port 44287 ssh2
Can you add "debug" to the pam routines that are called? Not
iut looks like the pam service name is sshd-gssapi. (Or other if
you are not using sshd-gssapi.)
Andrea wrote:
> On 8 Feb, 18:21, "Douglas E. Engert" <deeng... at anl.gov> wrote:
>> Andrea wrote:
>>> On 7 Feb, 20:37, "Douglas E. Engert" <deeng... at anl.gov> wrote:
>>>> Andrea wrote:
>>>>> Hi all,
>>>>> I'm experiencing some problem on kerberizing ssh on Solaris 9 with MIT
>>>>> Kerberos,
>>>>> I have the following setting:
>>>>> 1. Sun Solaris 5.9
>>>>> 2. MIT Kerberos KDC 1.6.3 ( I use just the kdc from the MIT Kerberos)
>>>>> 3. On Kerberos client side I used the one from Solaris from the
>>>>> following packet: SUNWkrbu
>>>>> 4. Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f
>>>> I don't believe the Solars 9 sshd supports GSSAPI which is what you
>>>> are looking for. On Solaris 9 we use OpenSSH and the MIT Kerberos.
>>>> (/usr/bin/ldd /usr/lib/ssh/sshd does not show any Kerberos or gssapi libs.)
>>> If i type ldd /usr/lib/ssh/sshd I obtain following result:
>>> root at colcascms # ldd /usr/lib/ssh/sshd
>>> libsocket.so.1 => /usr/lib/libsocket.so.1
>>> libnsl.so.1 => /usr/lib/libnsl.so.1
>>> libz.so.1 => /usr/lib/libz.so.1
>>> libpam.so.1 => /usr/lib/libpam.so.1
>>> libbsm.so.1 => /usr/lib/libbsm.so.1
>>> libwrap.so.1 => /usr/sfw/lib/libwrap.so.1
>>> libmd5.so.1 => /usr/lib/libmd5.so.1
>>> libcmd.so.1 => /usr/lib/libcmd.so.1
>>> libgss.so.1 => /usr/lib/libgss.so.1
>>> libc.so.1 => /usr/lib/libc.so.1
>>> libdl.so.1 => /usr/lib/libdl.so.1
>>> libmp.so.2 => /usr/lib/libmp.so.2
>>> libxfn.so.2 => /usr/lib/libxfn.so.2
>>> /usr/platform/SUNW,Sun-Fire-V440/lib/libmd5_psr.so.1
>>> /usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1
>>> And then I investigate about how ssh call the library libgss (with
>>> truss) and seems that ssh through libgss tries to obtain the ticket
>>> credential, this is part of the truss command launched as follow truss
>>> -u mech_krb5,libgss:: ssh user at hostaname:
>>> -> libgss:gss_acquire_cred(0xffbff660, 0x0, 0x0, 0x116938)
>>> open("/var/run/rpc_door/rpc_100029.1", O_RDONLY) Err#2 ENOENT open("/
>>> var/run/rpc_door/rpc_100029.1", O_RDONLY) Err#2 ENOENT
>>> getuid() = 0 [0]
>>> open("/tmp/krb5cc_0", O_RDONLY) Err#2 ENOENT
>>> open("/tmp/krb5cc_0", O_RDONLY) Err#2 ENOENT
>>> <- libgss:gss_acquire_cred() = 0x70000
>>> It seems that this ssh supports in such a way GSS-API.
>> I stand corrected, it looks like it does support GSSAPI.
>>
>>
>>
>>> Any further suggestions??
>> As root run another server in the forground:
>>
>> /usr/lib/ssh/sshd -ddd -p 2222
>>
>> The on a client, as a user (not root) with tickets:
>>
>> /usr/bin/ssh -vvv -p 2222 hostname
>>
>>
>>
>>
>>
>>> Thanks for the precious suggesstions.
>>> Bye
>>>> But On Solairs 10, The Sun ssh/sshd does support GSSAPI, and works
>>>> well with GSSAPI using the Sun Kerberos.
>>>>> This is my pam.conf:
>>>>> # PAM configuration
>>>>> #
>>>>> # Customized to try pam_unix, then pam_krb5
>>>>> #
>>>>> # Unless explicitly defined, all services use the modules
>>>>> # defined in the "other" section.
>>>>> #
>>>>> # Modules are defined with relative pathnames, i.e., they are
>>>>> # relative to /usr/lib/security/$ISA. Absolute path names, as
>>>>> # present in this file in previous releases are still acceptable.
>>>>> #
>>>>> # Authentication
>>>>> #
>>>>> # passwd command (explicit because of a different authentication
>>>>> module)
>>>>> #
>>>>> passwd auth required pam_passwd_auth.so.1
>>>>> #
>>>>> # Default definition for Authentication management
>>>>> # Used when service name is not explicitly mentioned for
>>>>> authentication
>>>>> # management
>>>>> #
>>>>> other auth requisite pam_authtok_get.so.1
>>>>> other auth sufficient pam_unix_auth.so.1
>>>>> other auth required pam_krb5.so.1 use_first_pass debug
>>>>> #
>>>>> # Account
>>>>> #
>>>>> # cron service (explicit because of non-usage of pam_roles.so.1)
>>>>> #
>>>>> cron account required pam_projects.so.1
>>>>> cron account required pam_unix_account.so.1
>>>>> # See notes about pam_krb5 in "other" section below
>>>>> cron account optional pam_krb5.so.1 debug
>>>>> #
>>>>> # Default definition for Account management
>>>>> # Used when service name is not explicitly mentioned for account
>>>>> management
>>>>> #
>>>>> other account requisite pam_roles.so.1
>>>>> other account required pam_projects.so.1
>>>>> other account required pam_unix_account.so.1
>>>>> # According to the pam_krb5 man page, this checks for password
>>>>> expiration.
>>>>> # I'm not sure this does anything since I've flagged it as optional.
>>>>> # I'm not sure if I can make it required because of root.
>>>>> other account optional pam_krb5.so.1 debug
>>>>> #
>>>>> # Session
>>>>> #
>>>>> # Default definition for Session management
>>>>> # Used when service name is not explicitly mentioned for session
>>>>> management
>>>>> #
>>>>> other session optional pam_krb5.so.1 debug
>>>>> other session required pam_unix_session.so.1
>>>>> #
>>>>> # Password
>>>>> #
>>>>> # (Don't list pam_krb5 here, this section is only for root. Regular
>>>>> # users must use the centralized department password changing
>>>>> mechanism.)
>>>>> #
>>>>> # Default definition for Password management
>>>>> # Used when service name is not explicitly mentioned for password
>>>>> management
>>>>> #
>>>>> other password requisite pam_authtok_get.so.1
>>>>> other password requisite pam_authtok_check.so.1
>>>>> other password required pam_authtok_store.so.1
>>>>> #
>>>>> I can ssh into the machine using the password from kerberos, when I
>>>>> let in I have the two tickets (TGT and TGS), but if I try to ssh on
>>>>> the same machine I have to retype the password, hence single sign on
>>>>> seems not working.
>>>>> Anyone can suggest me where am i wrong???
>>>>> Is the pam.conf correct?
>>>>> Does native Solaris ssh supports well gssapi delegation credentials??
>>>> It does on Solaris 10!
>>>>> My goal is to obtain single sign on with as much as possible native
>>>>> solaris tool, with just an exception use MIT KERBEROS KDC SERVER!
>>>> We do that on Solaris 10 but using Windows AD as the KDC.
>>>>> Thanks in advance!
>>>>> ________________________________________________
>>>>> Kerberos mailing list Kerbe... at mit.edu
>>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>> --
>>>> Douglas E. Engert <DEEng... at anl.gov>
>>>> Argonne National Laboratory
>>>> 9700 South Cass Avenue
>>>> Argonne, Illinois 60439
>>>> (630) 252-5444
>>> ________________________________________________
>>> Kerberos mailing list Kerbe... at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>> --
>>
>> Douglas E. Engert <DEEng... at anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
>
> This is the output of the sshd launched as you suggested:
> debug3: cipher ok: aes128-cbc [aes128-cbc,blowfish-cbc,3des-cbc]
> debug3: cipher ok: blowfish-cbc [aes128-cbc,blowfish-cbc,3des-cbc]
> debug3: cipher ok: 3des-cbc [aes128-cbc,blowfish-cbc,3des-cbc]
> debug3: ciphers ok: [aes128-cbc,blowfish-cbc,3des-cbc]
> debug2: mac_init: found hmac-sha1
> debug3: mac ok: hmac-sha1 [hmac-sha1,hmac-md5]
> debug2: mac_init: found hmac-md5
> debug3: mac ok: hmac-md5 [hmac-sha1,hmac-md5]
> debug3: macs ok: [hmac-sha1,hmac-md5]
> debug1: sshd version Sun_SSH_1.1
> debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
> debug1: read PEM private key done: type RSA
> debug1: private host key: #0 type 1 RSA
> debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
> debug1: read PEM private key done: type DSA
> debug1: private host key: #1 type 2 DSA
> debug1: Bind to port 2222 on ::.
> Server listening on :: port 2222.
> debug1: Server will not fork when running in debugging mode.
> Connection from 11.10.243.5 port 44287
> debug1: Client protocol version 2.0; client software version
> Sun_SSH_1.1
> debug1: no match: Sun_SSH_1.1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-Sun_SSH_1.1
> debug1: list_hostkey_types: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
> hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
> debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: i-default,en
> debug2: kex_parse_kexinit: i-default,en
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: GSS-API Mechanism encoded as toWM5Slw5Ew8Mqkay+al2g==
> debug1: SSH2_MSG_KEXINIT sent
> debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0
> && !0
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay
> +al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
> debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: i-default,en
> debug2: kex_parse_kexinit: i-default,en
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay
> +al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,null
> debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
> cbc,blowfish-cbc
> debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
> cbc,blowfish-cbc
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: i-default
> debug2: kex_parse_kexinit: i-default
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: mac_init: found hmac-md5
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug2: mac_init: found hmac-md5
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: Peer sent proposed langtags, ctos: i-default
> debug1: Peer sent proposed langtags, stoc: i-default
> debug1: We proposed langtags, ctos: i-default,en
> debug1: We proposed langtags, stoc: i-default,en
> debug1: Negotiated main locale: C
> debug1: Negotiated messages locale: C
> debug1: Wait SSH2_MSG_GSSAPI_INIT
> debug1: gss_complete
> debug1: dh_gen_key: priv key bits set: 121/256
> debug1: bits set: 538/1024
> debug1: bits set: 526/1024
> 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: KEX done
> debug1: userauth-request for user icm service ssh-connection method
> none
> debug1: attempt 0 initial attempt 0 failures 0 initial failures 0
> debug2: input_userauth_request: setting up authctxt for icm
> debug2: input_userauth_request: try method none
> Failed none for icm from 11.10.243.5 port 44287 ssh2
> debug1: userauth-request for user icm service ssh-connection method
> gssapi-keyex
> debug1: attempt 1 initial attempt 0 failures 1 initial failures 0
> debug2: input_userauth_request: try method gssapi-keyex
> debug2: Mapping initiator GSS-API principal to local username
> debug2: Mapped the initiator to: icm
> debug2: Starting PAM service sshd-gssapi for method gssapi-keyex
> debug3: Trying to reverse map address 11.10.243.5.
> Failed gssapi-keyex for icm from 11.10.243.5 port 44287 ssh2
> debug1: userauth-request for user icm service ssh-connection method
> gssapi-with-mic
> debug1: attempt 2 initial attempt 0 failures 2 initial failures 0
> debug2: input_userauth_request: try method gssapi-with-mic
> debug1: Client offered gssapi userauth with { 1 2 840 113554 1 2 2 }
> (supported)
> debug2: Mapping initiator GSS-API principal to local username
> debug2: Mapped the initiator to: icm
> debug2: Starting PAM service sshd-gssapi for method gssapi-with-mic
> Failed gssapi-with-mic for icm from 11.10.243.5 port 44287 ssh2
> debug1: userauth-request for user icm service ssh-connection method
> keyboard-interactive
> debug1: attempt 3 initial attempt 0 failures 3 initial failures 0
> debug2: input_userauth_request: try method keyboard-interactive
> debug1: keyboard-interactive devs
> debug2: Starting PAM service sshd-kbdint for method keyboard-
> interactive
> debug2: Calling pam_authenticate()
> debug2: PAM echo off prompt: Password:
> debug2: Nesting dispatch_run loop
>
>
>
>
> While the output for the client is the following:
>
>
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Rhosts Authentication disabled, originating port will not be
> trusted.
> debug1: ssh_connect: needpriv 0
> debug1: Connecting to colcascms.SOLARIS [11.10.243.5] port 2222.
> debug1: Connection established.
> debug1: identity file /.ssh/identity type -1
> debug1: identity file /.ssh/id_rsa type -1
> debug1: identity file /.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version
> Sun_SSH_1.1
> debug1: no match: Sun_SSH_1.1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-Sun_SSH_1.1
> debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
> hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
> cbc,blowfish-cbc
> debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
> cbc,blowfish-cbc
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: i-default
> debug2: kex_parse_kexinit: i-default
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug1: ssh_gssapi_init_ctx(115ad0, colcascms.solaris, 0, 0, ffbff5bc)
> debug3: ssh_gssapi_import_name: snprintf() returned 22, expected 23
> debug2: GSS-API Mechanism encoded as toWM5Slw5Ew8Mqkay+al2g==
> debug1: SSH2_MSG_KEXINIT sent
> debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0
> && !0
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay
> +al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,null
> debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
> cbc,blowfish-cbc
> debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
> cbc,blowfish-cbc
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: i-default
> debug2: kex_parse_kexinit: i-default
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay
> +al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
> debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: i-default,en
> debug2: kex_parse_kexinit: i-default,en
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: mac_init: found hmac-md5
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug2: mac_init: found hmac-md5
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: Peer sent proposed langtags, ctos: i-default,en
> debug1: Peer sent proposed langtags, stoc: i-default,en
> debug1: We proposed langtags, ctos: i-default
> debug1: We proposed langtags, stoc: i-default
> debug1: Negotiated lang: i-default
> debug1: dh_gen_key: priv key bits set: 123/256
> debug1: bits set: 526/1024
> debug1: Calling gss_init_sec_context
> debug1: ssh_gssapi_init_ctx(168a58, colcascms.solaris, 1, 0, ffbff67c)
> debug1: Delegating GSS-API credentials
> debug3: ssh_gssapi_import_name: snprintf() returned 22, expected 23
> 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(168a58, colcascms.solaris, 1, ffbff684,
> ffbff67c)
> debug1: Delegating GSS-API credentials
> debug1: bits set: 538/1024
> debug3: check_host_in_hostfile: filename /.ssh/known_hosts
> debug3: check_host_in_hostfile: match line 7
> debug3: check_host_in_hostfile: filename /.ssh/known_hosts
> debug3: check_host_in_hostfile: match line 1
> debug1: Host 'colcascms.solaris' is known and matches the advertised
> RSA hostkey.
> debug1: Found key in /.ssh/known_hosts:7
> 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(169730, colcascms.solaris, 0, 0, ffbff63c)
> debug3: ssh_gssapi_import_name: snprintf() returned 22, expected 23
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1: ssh_gssapi_init_ctx(168ad0, colcascms.solaris, 1, 0, ffbff718)
> debug1: Delegating GSS-API credentials
> debug3: ssh_gssapi_import_name: snprintf() returned 22, expected 23
> debug1: ssh_gssapi_init_ctx(168ad0, colcascms.solaris, 1, ffbff720,
> ffbff714)
> 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
> debug3: authmethod_lookup publickey
> debug3: remaining preferred: keyboard-interactive,password
> debug3: authmethod_is_enabled publickey
> debug1: Next authentication method: publickey
> debug1: Trying private key: /.ssh/identity
> debug3: no such identity: /.ssh/identity
> debug1: Trying private key: /.ssh/id_rsa
> debug3: no such identity: /.ssh/id_rsa
> debug1: Trying private key: /.ssh/id_dsa
> debug3: no such identity: /.ssh/id_dsa
> debug2: we did not send a packet, disable method
> debug3: authmethod_lookup keyboard-interactive
> debug3: remaining preferred: password
> debug3: authmethod_is_enabled keyboard-interactive
> debug1: Next authentication method: keyboard-interactive
> debug2: userauth_kbdint
> debug2: we sent a keyboard-interactive packet, wait for reply
> debug2: input_userauth_info_req
> debug2: input_userauth_info_req: num_prompts 1
> Password:
>
>
>
> It seems the gssapi delegation works, I'm really stucked on this
> problem :-(
>
> Thanks in advance,
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list