Putty Kerberos/GSSAPI authentication
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.