Kerberized authentication with SecureCRT 4.1.8
rachel elizabeth dillon
GSSAPI using method external-keyx. I want to be able to connect to this
realm from a Windows machine. The owner of the realm has a SecureCRT
license, so I started there. With MIT KfW 2.6.5 installed on the machine
(which is running Windows 2003), I am able to make a connection which gets
me a host ticket and the pre-login banner but then fails with an error of
"GSSAPI authentication with the server could not be completed." Running
an sshd -d -d -d on the server machine, I see that it tries to connect
first with method "none," which tries to use PAM and fails (PAM is not
configured on this server past the defaults), and then tries to use method
"gssapi," which fails as follows:
Failed none for ptadmin from 10.1.16.31 port 1733 ssh2
debug1: userauth-request for user ptadmin service ssh-connection method gssapi
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method gssapi
debug3: mm_request_send entering: type 28
debug3: monitor_read: checking request 28
debug3: mm_request_send entering: type 29
debug3: mm_request_receive entering
debug3: mm_request_receive_expect entering: type 29
debug3: mm_request_receive entering
Failed gssapi for ptadmin from 10.1.16.31 port 1733 ssh2
Received disconnect from 10.1.16.31: 14: Unable to authenticate using any of the configured authentication methods.
A successful request from another Solaris machine with OpenSSH and krb5
support looks like this:
Failed none for ptadmin from 10.1.16.234 port 54138 ssh2
debug1: userauth-request for user ptadmin service ssh-connection method external-keyx
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method external-keyx
debug3: mm_request_send entering: type 26
debug3: mm_request_receive_expect entering: type 27
debug3: mm_request_receive entering
debug3: monitor_read: checking request 26
Authorized to ptadmin, krb5 principal pta...@IC.COM (krb5_kuserok)
debug3: mm_answer_gss_userok: sending result 1
debug3: mm_request_send entering: type 27
debug2: pam_acct_mgmt() = 0
debug3: mm_ssh_gssapi_userok: user authenticated
Accepted external-keyx for ptadmin from 10.1.16.234 port 54138 ssh2
debug3: mm_send_keystate: Sending new keys: 7b3c0 81910
debug3: mm_newkeys_to_blob: converting 7b3c0
debug3: mm_newkeys_to_blob: converting 81910
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type 38
debug3: mm_send_keystate: Finished sending state
debug1: PAM establishing creds
Accepted gssapi for ptadmin from 10.1.16.234 port 54138 ssh2
It looks to me like I either want SecureCRT to connect via "external-keyx,"
or I want to convince the sshd to parse "gssapi" in a different way.
I would also be interested in solutions that involve another SSH client for
Windows, if that client were free.
Thanks for any help you can provide,
-r.
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Douglas E. Engert
rachel elizabeth dillon wrote:
> I have an existing MIT Kerberos realm with Kerberized SSH logins over
> GSSAPI using method external-keyx. I want to be able to connect to this
> realm from a Windows machine. The owner of the realm has a SecureCRT
> license, so I started there. With MIT KfW 2.6.5 installed on the machine
> (which is running Windows 2003), I am able to make a connection which gets
> me a host ticket and the pre-login banner but then fails with an error of
> "GSSAPI authentication with the server could not be completed." Running
> an sshd -d -d -d on the server machine, I see that it tries to connect
> first with method "none," which tries to use PAM and fails (PAM is not
> configured on this server past the defaults), and then tries to use method
> "gssapi," which fails as follows:
>
It should work, I have used SecureCRT-4.1.3 with KfW to OpenSSH sshd versions 3.1,
through 3.9. Note that the gssapi code was changed to gssapi-with-mic
as there was a security problem. SecureCRT should work with either.
Earlier veriosns of OpenSSH with Simon's patch could do the gssapi external
key. The 3.8 and 3.9 dont have that, but have the auth method gsspia-with-mic.
Since your trace says gssapi rather then gssapi-with-mic, it might be
out of date.
What version of the OPenSSH are you rinning?
OpenSSH-3.8 and 3.9 can do the gssapi-with-mic and so can SecureCRT.
> I would also be interested in solutions that involve another SSH client for
> Windows, if that client were free.
>
Putty-0.54 with patches can do gssapi-with-mic
> Thanks for any help you can provide,
>
> -r.
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Sam Hartman
Douglas> rachel elizabeth dillon wrote:
>> I have an existing MIT Kerberos realm with Kerberized SSH
>> logins over GSSAPI using method external-keyx. I want to be
>> able to connect to this realm from a Windows machine. The owner
>> of the realm has a SecureCRT license, so I started there. With
>> MIT KfW 2.6.5 installed on the machine (which is running
>> Windows 2003), I am able to make a connection which gets me a
>> host ticket and the pre-login banner but then fails with an
>> error of "GSSAPI authentication with the server could not be
>> completed." Running an sshd -d -d -d on the server machine, I
>> see that it tries to connect first with method "none," which
>> tries to use PAM and fails (PAM is not configured on this
>> server past the defaults), and then tries to use method
>> "gssapi," which fails as follows:
>>
Douglas> It should work, I have used SecureCRT-4.1.3 with KfW to
Douglas> OpenSSH sshd versions 3.1, through 3.9. Note that the
Douglas> gssapi code was changed to gssapi-with-mic as there was a
Douglas> security problem. SecureCRT should work with either.
I believe Rachel is running into a bug in my Debian packages. I think
I understand what's going on. I managed to misapply part of Simon's
3.6 patches such that the Debian server cannot deal with a
properly-encoded OID.