gssapi-with-mic and Win2K KDC?

[Douglas E. Engert]

Aaron Grewell wrote:
> 
> On Fri, 2004-05-28 at 10:39, Douglas E. Engert wrote:
> > Aaron Grewell wrote:
> > >
> > > Upgrading to the 3.8.x versions of OpenSSH appears to have broken
> > > support for Win2K KDC's.  Win2K supports gssapi just fine, but the new
> > > gssapi-with-mic does not appear to work.
> >
> > It works for us. We have used W2000 ADs, and they are now all W2003 ADs.
> > OpenSSH-3.8p1.
> >
> > What type of errors are you seeing?
> >
> 
> Oh goody.  Maybe I've just borked something.  I've got my Linux boxes
> (RHEL3) set up for PAM authentication to Win2K via Kerberos.  This works
> fine, so I'm pretty sure I haven't screwed up the Kerberos end of it.
> Also, if I turn off Kerberos and GSSAPI and turn on PAM in OpenSSH this
> also works fine.  However, I would like to be able to use both password
> authentication and ticket-based passwordless authentication for those
> hosts that support it.  Thus the need for GSSAPI support.
> 
> > The comunity should be making an effort to move towards geting rid
> > of the gssapi, and move to the gssapi-with-mic with all due haste.
> >
> 
> Sure, but this is MS we're talking about.  "Community who?"

I don't see MS fits in here. Its only the KDC. The difference between
the gsspia and gssapi-with-mic is the the with-mic uses gss_wrap/unwrap
to bind the session keys to the authenication. Even if you had a
Windows ssh client the used the SSPI it caould do the gssapi-wit-mic.
(SecureCRT for example can do this.)  

> 
> But back to the authentication issues.  When I try to login via GSSAPI
> with or without a ticket in 3.8.x it prompts for a password, then
> refuses my password, as though I had typed it improperly.  The same
> UID/password through PAM works fine.  More detail:
> 
> With ssh 3.8.1p1 on both client and server
> 
> On the ssh server:
> # GSSAPI options
> GSSAPIAuthentication yes
> GSSAPICleanupCredentials yes
> 
> On the client:
> [localaccount at workstation localaccount]$ ssh adminaccount at server.uwb.edu
> -vvv

Try using  "ssh -vvv -l adminaccount server.uwb.edu" 

I tried something using user at host and it failed, but -l user host works. 

> OpenSSH_3.8.1p1, OpenSSL 0.9.7a Feb 19 2003
> debug1: Reading configuration data /home/localaccount/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to server.uwb.edu [216.186.72.7] port 22.
> debug1: Connection established.
> debug1: identity file /home/localaccount/.ssh/identity type -1
> debug1: identity file /home/localaccount/.ssh/id_rsa type -1
> debug1: identity file /home/localaccount/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, remote software version
> OpenSSH_3.8.1p1
> debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
> diffie-hellman-group-exchange-sha1,diffie-hellman-gro
> up1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
> aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
> tr
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
> aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
> tr
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
> ssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
> ssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit:
> diffie-hellman-group-exchange-sha1,diffie-hellman-gro
> up1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
> aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
> tr
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
> aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
> tr
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
> ssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
> ssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> 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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug2: dh_gen_key: priv key bits set: 115/256
> debug2: bits set: 503/1024
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug3: check_host_in_hostfile: filename
> /home/localaccount/.ssh/known_hosts
> debug3: check_host_in_hostfile: match line 1
> debug3: check_host_in_hostfile: filename
> /home/localaccount/.ssh/known_hosts
> debug3: check_host_in_hostfile: match line 1
> debug1: Host 'server.uwb.edu' is known and matches the RSA host key.
> debug1: Found key in /home/localaccount/.ssh/known_hosts:1
> debug2: bits set: 496/1024
> debug1: ssh_rsa_verify: signature correct
> debug2: kex_derive_keys
> debug2: set_newkeys: mode 1
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug2: set_newkeys: mode 0
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug2: key: /home/localaccount/.ssh/identity ((nil))
> debug2: key: /home/localaccount/.ssh/id_rsa ((nil))
> debug2: key: /home/localaccount/.ssh/id_dsa ((nil))
> debug1: Authentications that can continue:
> publickey,gssapi-with-mic,password,ke
> yboard-interactive
> debug3: start over, passed a different list
> publickey,gssapi-with-mic,password,k
> eyboard-interactive
> debug3: preferred publickey,keyboard-interactive,password

What happened to gssapi-with-mic here? Does the sshd have 
a keytab with the host/<hostname>@<realm> principal?

Did the user do a kinit to get a ticket? 
On my system, I get:

debug1: Authentications that can continue: publickey,gssapi-with-mic,gssapi
debug3: start over, passed a different list publickey,gssapi-with-mic,gssapi
debug3: preferred gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Delegating credentials

> debug3: authmethod_lookup publickey
> debug3: remaining preferred: keyboard-interactive,password
> debug3: authmethod_is_enabled publickey
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/localaccount/.ssh/identity
> debug3: no such identity: /home/localaccount/.ssh/identity
> debug1: Trying private key: /home/localaccount/.ssh/id_rsa
> debug3: no such identity: /home/localaccount/.ssh/id_rsa
> debug1: Trying private key: /home/localaccount/.ssh/id_dsa
> debug3: no such identity: /home/localaccount/.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
> debug1: Authentications that can continue:
> publickey,gssapi-with-mic,password,ke
> yboard-interactive
> debug3: userauth_kbdint: disable: no info_req_seen
> debug2: we did not send a packet, disable method
> debug3: authmethod_lookup password
> debug3: remaining preferred:
> debug3: authmethod_is_enabled password
> debug1: Next authentication method: password
> adminaccount at server.uwb.edu's password:
> debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue:
> publickey,gssapi-with-mic,password,ke
> yboard-interactive
> Permission denied, please try again.
> adminaccount at server.uwb.edu's password:
> debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue:
> publickey,gssapi-with-mic,password,ke
> yboard-interactive
> Permission denied, please try again.
> adminaccount at server.uwb.edu's password:
> debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue:
> publickey,gssapi-with-mic,password,ke
> yboard-interactive
> debug2: we did not send a packet, disable method
> debug1: No more authentication methods to try.
> Permission denied
> (publickey,gssapi-with-mic,password,keyboard-interactive).

-- 

 Douglas E. Engert  <DEEngert at anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444