11

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.
xdfil
  • 481
  • 2
  • 6
  • 15
  • 1
    Turning on debug on the ssh daemon night show useful info. You can always start a second instance on a different port for testing. – Paul Haldane Nov 25 '14 at 08:07

3 Answers3

10

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.

Update: As of Windows 10 version 21H1 and Windows Server 2022, the OpenSSH for Windows (version 8.1 or newer) client and server built into Windows now also support GSSAPI authentication and delegation (i.e., ssh -K). So if all you need is that, as of 2021 you no longer need to install PuTTY and MIT Kerberos.

Markus Kuhn
  • 871
  • 8
  • 8
  • 1
    I have since learnt that Windows does actually have a kind-of equivalent of MIT Kerberos' `kinit` command called [`cmdkey`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/cmdkey). – Markus Kuhn Jan 15 '19 at 14:07
  • 1
    Regarding enabling ticket delegation, if you are one of those who understand that _Active Directory_ is really just _Microsoft LDAPv3_ under the hood: make sure the LDAP entry of the service principal you want to be able to delegate a Kerberos ticket to has in its [userAccountControl](https://support.microsoft.com/en-gb/help/305144/how-to-use-the-useraccountcontrol-flags-to-manipulate-user-account-pro) the bit TRUSTED_FOR_DELEGATION = 0x80000 = 524288 set. – Markus Kuhn Jan 15 '19 at 14:43
  • FYI to anyone considering configuring "Trust this computer for delegation to any service (Kerberos only)", e.g. unconstrained Kerberos delegation, this has SERIOUS security implications you should consider. I’d recommend reading https://adsecurity.org/?p=1667 first. – Brad Aug 22 '19 at 16:08
4

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.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • 1
    klist tgt looks like it makes sense to me. says it's forwardable too. klist shows 5 keys, for things like Exchange. I also have a ticket for the Linux server I am trying to ssh to. I've gone over the putty config 100 times. All the online docs/ guides pretty much say the same thing so I'm confident that part is set up right. – xdfil Nov 25 '14 at 08:10
4

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: 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.

xdfil
  • 481
  • 2
  • 6
  • 15