I configured a few Linux servers to authenticate with Active Directory Kerberos using sssd on RHEL6. I also enabled GSSAPI authentication in hopes of passwordless logins.
But I can't seem to get Putty (0.63) to authenticate without a password.
GSSAPI works between Linux systems (openSSH client) that are configured for AD authentication, using the .ssh/config settings to enable GSSAPI.
It also works from Cygwin (openSSH client), using the same .ssh/config settings as well as running the kinit command to get a ticket.
Also Samba shares on all of the Linux systems, including home directories work from Windows Explorer without requiring a password (I'm not sure if GSSAPI comes into play there)
What sort of things can I try to troubleshoot this? Most of my users use Putty. Also, I am not a Windows Admin so I can't do anything on the domain controllers. My account only has privileges to add servers to the AD Domain.
I turned on putty SSH packet logging. I found this sort of interesting, I'm not sure what to do with this information yet:
Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Best Answer
On Windows machines that are part of an Active Directory domain, users receive their Kerberos ticket-granting ticket when they log into Windows, and PuTTY is able to use that for authentication if GSSAPI authentication is enabled in PuTTY Configuration Connection|SSH|Auth|GSSAPI (and other authentication methods that it tries before GSSAPI, such as public-key via Pageant, are not set up or disabled in Connection|SSH|Auth).
[If you also need ticket delegation (e.g., to mount kerberized file systems on the server after login), make sure that GSSAPI delegation is also enabled in PuTTY, and the servers to which you login are marked in Active Directory in the Delegation tab as "Trust this computer for delegation to any service (Kerberos only)", which they are not by default. That latter trust setting in AD is strangely only needed for delegation to work from Windows clients like PuTTY; it is not needed for Linux "ssh -K" clients.]
On self-managed (personal) Windows machines that are not part of an Active Directory domain, you can still use Kerberos/GSSAPI authentication (and ticket delegation) via PuTTY, but you have to get the ticket yourself. Unfortunately, Windows 7 does not come installed with any equivalent of the kinit program (for you to manually request a ticket), and PuTTY also does not prompt you for your Kerberos password either if you lack a ticket. Therefore, you have to install the MIT Kerberos for Windows package, which includes both the usual kinit/klist/kdestroy command-line tools, as well as a neat GUI tool "MIT Kerberos Ticket Manager". Use those to get your ticket, and then PuTTY will automatically use the MIT GSSAPI library instead of the Microsoft SSPI one, and it should all work. If the "MIT Kerberos Ticket Manager" is running, it will automatically prompt you for your Kerberos password when PuTTY needs a ticket, so it is a good idea to link it from the Startup folder.