Putty Kerberos/GSSAPI authentication
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.
Solution 1:
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.
Solution 2:
First double check that your klist output on the Windows box running PuTTY shows a valid TGT. Then in the config for your PuTTY session, make sure Attempt GSSAPI authentication is enabled in Connection - SSH - Auth - GSSAPI. Finally, make sure it's configured to login with your username automatically in Connection - Data. You can either explicitly specify the username or select the radio button for Use system username.
Historically, that's all I've needed to do to make passwordless SSH login work via Kerberos.
Solution 3:
The problem was in the Windows Kerberos setup. I think our Active Directory is set up funky, I don't really know I'm not a Windows admin.
But I fixed the problem by manually configuring Kerberos using ksetup in the Windows 7 CLI.
After a reboot to my remote workstation I couldn't log in to my PC. That is because in the original configuration the TLD portion of my realm domain was always absent (domain\user) but after I manually configured it I had to change my login domain to reflect the full realm domain name (domain.TLD\user) and I was able to log in to my Windows PC, although it seems to take longer to authenticate now.
Prior to the changes the output of ksetup only showed my default realm, and it was in lower case.
I used " nslookup -type=SRV _kerberos._tcp.domain.TLD " to get all the kdc servers for my realm.
I did not set any flags.
I set mapped my username " ksetup /mapuser [email protected] user "
Resources I used: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC
https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html
If anyone has any suggestions I can give to the Windows admin folks on how they can fix this (is it broken?) I'll pass it along.