Skip to main content

Putty Kerberos/GSSAPI authentication [Resolved]

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)
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)

Question Credit: xdaxdb
Question Reference
Asked January 11, 2019
Posted Under: Network
3 Answers

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.

credit: Ryan Bolger
Answered January 11, 2019

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 user@domain.TLD user "

Resources I used:

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.

credit: xdaxdb
Answered January 11, 2019
Your Answer