GSSAPI auth not working

[blakeduffey]

I have installed 7.9.0.0p1-beta on a domain joined Windows 2016 server. I've made a copy of sshd_config_default (named sshd_config). In sshd_config I've uncommented the line GSSAPIAuthentication and changed 'no' to 'yes'.

I have then installed and started the service. I can connect to ssh (from a remote machine, also domain joined) and connect via name/password, but GSSAPI isn't working. I'm simply prompted for a password when I connect. I have the same behavior when running sshd.exe in debug mode. I've tried putty and the same version of OpenSSH client.

I'd appreciate any thoughts on what I'm missing. We use Kerberos to connect to sshd on linux (so I'm pretty familiar with the process) and have no issues overall.

[jborean93]

On your linux host, can you see a ticket for the account you want to auth with in klist?

[NoMoreFood]

Are you running the client with ssh -K? If you enable debugging server/client side then it should give some good messages about attempting to obtain the SPN. Make sure you're using the hostname if you don't have the IP addressed registered as an SPN.

[blakeduffey]

Are you running the client with ssh -K? If you enable debugging server/client side then it should give some good messages about attempting to obtain the SPN. Make sure you're using the hostname if you don't have the IP addressed registered as an SPN.

I've tried using PuTTY (with GSSAPI enabled) and I've tried using ssh.exe -K (using the FQDN)

On the server debug, i see the user principal lookup (redacted slightly)

debug3: lookup_principal_name: Successfully discovered explicit principal name: 'edge\bduffey'=>'bduffey@edge.domain.tld'

So I feel like the client and server are talking and it is properly getting the user principal.

I'm seeing something in the log that could be pointing to an issue right after that

debug3: LsaLogonUser Succeeded (Impersonation: 0)
debug1: user edge\bduffey matched group list administrators at line 87
debug3: match found
debug3: reprocess config:88 setting AuthorizedKeysFile PROGRAMDATA/ssh/administrators_authorized_keys

My user account is an admin - is there something special I need to do to allow logon?

Also on the client side after enabling verbose I see

debug1: Authentications that can continue: publickey,password,keyboard-interactive

Which makes me think that it isn't allowing GSSAPI auth?

[NoMoreFood]

It roughly sounds like you've done everything correctly. Try commenting out the administrators_authorized_keys stuff in sshd_config.

[blakeduffey]

so when I do that I get:

debug1: get_passwd: LookupAccountName() failed: 1332.

(I wasn't getting this before)

[NoMoreFood]

Are the user account and the computer in the same forest?

[blakeduffey]

They are in the same domain (the end goal will be two separate domains in a one-way trust scenario, but in my test case there are in the same domain)

[NoMoreFood]

@blakeduffey Ultimately you'd have to do a two way trust with selective authentication to allow the OpenSSH to, at a minimum, enumerate the domain controllers for name resolution purposes. That's a different problem though.

Can you attach a server-side log with DEBUG3 enabled with a single connection attempt in the log? See https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

[mgkuhn]

Windows Kerberos clients do additional LDAP checks on the Active Directory server compared to the Linux implementation of Kerberos, so it is possible that there is something in your Active Directory user or computer object not yet set correctly (common issues include: AES encryption type not being enabled, the server not being trusted for delegation, the SPN or domain not matching the DNS entry).

When you otherwise log into that Windows machine, do you see Kerberos tickets with klist? If not you are using NTLM instead because something in your Windows Kerberos setup is broken. (You can disable NTLM entirely to make sure Kerberos actually works on Windows.)

[maertendMSFT]

Please look at the response from nomorefood, if there are more issues, please reopen