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" <[EMAIL PROTECTED]> wrote: >> Andrea wrote: >>> On 7 Feb, 20:37, "Douglas E. Engert" <[EMAIL PROTECTED]> 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: >>> [EMAIL PROTECTED] # 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 [EMAIL PROTECTED]: >>> -> 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 [EMAIL PROTECTED] >>>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> -- >>>> 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 >> -- >> >> Douglas E. Engert <[EMAIL PROTECTED]> >> 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@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos