Add support for GSSAPIKeyExchange

[coztoolkit]

The currently published code supports GSSAPIAuthentication, but not GSSAPIKeyExchange. It would be very useful to have this support. Most modern Linux distros support this option, and given the Kerberos integration with AD, it seems to make sense for a Windows port to have this feature.

https://github.com/SimonWilkinson/gss-openssh/ contains the base code for most of the Linux patches.

[damnhandy]

👍

[CJHarmath]

+1
Supporting proper Kerberos in a cross platform environment is a key feature for enterprises heavily using Kerberos

[kirkwolf]

This is more than a cross platform issue - the ability to use GSSAPIKeyExchange with Kerberos or AD means that you can authenticate the host that you are connecting to without requiring that the user manage "known_hosts" registries. This is equally valuable in a pure Windows->WIndows SSH environment.

[manojampalam]

Yes. There is a plan to add this down the line - the SSPIs will, however, be used instead of other GSSAPI based modules (like MIT Kerb). Let us know if you have any concerns.

[mgkuhn]

A note on the choice of GSSAPI provider: the PuTTY ssh client supports both SSPI and MIT Kerberos for Windows as the underlying GSSAPI, and I have to use both routinely with PuTTY:

• I need SSPI when the client is a domain-managed machine, to use the Kerberos ticket I got when logging into Windows.
• If the Windows machine on which I run the PuTTY client is not in an Active Directory domain, then the only way I know to get a Kerberos ticket is to install "MIT Kerberos for Windows" and use the "MIT Kerberos Ticket Manager" to do the equivalent of running "kinit".

So unless SSPI does support some way to prompt for a Kerberos principal name and password and then fetches the required ticket after login (it apparently does not with PuTTY!), please make sure that your ssh client also supports the GSSAPI provided by MIT Kerberos for Windows (just as PuTTY does).

[ghost]

Whoa, SSPI support could mean easy smartcard auth to Windows and non-Windows sshd!

[kfiresmith]

+1

[dihmandrake]

I would love to see this implemented

[jimcroft]

FWIW in line with the comment from @mgkuhn using GSSAPIKeyExchange with MIT Kerberos is as important as ActiveDirectory for my use cases.

[DomDupuis]

+1

[mgkuhn]

I don't think the initial claim "The currently published code supports GSSAPIAuthentication." is true, at least not on Windows via SSPI. Where is that code? In order to perform GSSAPI authentication (and delegation) on Windows via the SSPI API, the ssh client would have to call InitializeSecurityContext() and the sshd server would have to call AcceptSecurityContext() and both have to pass the resulting GSSAPI tokens across the socket to the respective other side, and repeat this exchange of tokens to and fro until GSSAPI has done its thing. I cannot see currently any call to either InitializeSecurityContext() or AcceptSecurityContext() in the openssh-portable source code, so this is not even a construction site yet.

This issue is misnamed: first of all GSSAPIAuthentication via SSPI has yet to be supported. And only once that works, then related Kerberos options such as GSSAPIDelegateCredentials, GSSAPIKeyExchange, can also be added as well.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa374704(v=vs.85).aspx
https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/authentication-functions

[mgkuhn]

"There is a plan to add this [SSPI] down the line" Since three years have now passed: any timetable yet for looking into this? I personally would be most interested in having SSPI support for GSSAPIAuthentication and GSSAPIDelegateCredentials added to sshd, because my use case is that I have both Windows and macOS/Linux machines in the same Active Directory domain, and I would like to "kinit ; ssh -K" from macOS/Linux (or PuTTY from Windows) into the Windows machines and delegate my Kerberos ticket to the Windows sshd server such that it can access my files on my behalf on another file server. GSSAPIKeyExchange would an added bonus, but is far less essential (as that is just for host authentication). GSSAPI/SSPI support is far more urgent in the Windows sshd server than in the openssh Windows client, because the PuTTY folks have already done a Windows ssh client with GSSAPI long ago.

[kirkwolf]

Agreed, although a full implementation including GSSAPIKeyExchange for both ssh and sshd is really needed to make the product really interesting for our corporate clients. Maybe someone should start a crowd funded account for this feature? It might be interesting to the developers otherwise. It would be nice if there were a GSSAPI wrapper library for SSPI. Maybe there is? A quick search wasn't fruitful. In the mean time, there is this documentation: https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/sspi-kerberos-interoperability-with-gssapi Kirk Wolf Dovetailed Technologies http://dovetail.com

…

On Tue, Nov 20, 2018 at 10:58 AM Markus Kuhn ***@***.***> wrote: "There is a plan to add this [SSPI] down the line" Since three years have now passed: any timetable yet for looking into this? I personally would be most interested in having SSPI support for GSSAPIAuthentication and GSSAPIDelegateCredentials added to sshd, because my use case is that I have both Windows and Linux machines in the same Active Directory domain, and I would like to "kinit ; ssh -K" from Linux into the Windows machines and delegate my Kerberos ticket to the Windows server such that it can access my files on my behalf on another file server. GSSAPIKeyExchange would an added bonus, but is less essential (as that is just for host authentication). GSSAPI/SSPI support in the openssh Windows client is far less urgent, because the PuTTY folks have done that long ago. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ--Hpa09t-rviJSd4er3FqYT-S0cQ0pks5uxDTJgaJpZM4GSgGX> .

[coztoolkit]

Reply to mgkuhn: The issue is not misnamed; it was specifically opened to request that Microsoft take up the Simon Wilkinson patches which add GSSAPIKeyExchange support to the OpenSSH portable base. I was noting that OpenSSH supports GSSAPIAuthentication, not commenting on Microsoft's port of that code via SSPI. My wording should have been clearer.

Also (not that you are claiming otherwise) please note that the PuTTY standard distribution does not include GSSAPIKeyExchange support. Support for key exchange is being requested here for both the OpenSSH server and client on Windows.

If you are concerned about Microsoft's implementation (or lack of progress thereof) of GSSAPIAuthentication via SSPI, you should open a separate issue.

[mgkuhn]

Note that there are now well-working test binaries at #1295 available that finally make GSSAPIAuthentication and GSSAPIDelegateCredentials work for Kerberos and Active Directory using a new GSSAPI wrapper library for SSPI contributed to OpenSSH by @NoMoreFood. I can now simply "ssh -K -l 'domain\user' windows-box.org" password-free from Linux into my domain-joined Windows box without having to set up .ssh/authorized_keys there, and I can also automatically access Kerberos-protected filer shares on the windows box in that session thanks to the -K delegation of my Kerberos TGT.

As mentioned above, such a GSSAPI wrapper library for SSPI is obviously also a pre-requisite for GSSAPIKeyExchange to be implemented, so this patch should be an important step in that direction.

(BTW, getting this to work also exposed some configuration problems in one of our local cross-domain Active Directory setups, which still partially used NTLM rather than Kerberos by accident, due to "external trust" rather than "forest trust" being used, as only the latter properly supports Kerberos for Windows clients. You also need to enable in Active Directory "trusted for Kerberos delegation" for both the user and the Windows box. If "klist" shows no service ticket under Windows, you are not actually using Kerberos.)

[mgkuhn]

Reading through RFC 4462, I see that GSSAPIKeyExchange has been standardized so far only for rather old-fashioned integer/GF(p) Diffie-Hellman groups: gss-group1-sha1-*, gss-group14-sha1-*, gss-gex-sha1-*. These are the GSSAPI-authenticated equivalents of the KexAlgorithms options

diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group-exchange-sha1

which have been either disabled (group1) or are at the end of the modern preference list.

Has anyone already amended RFC 4462 to specify GSSAPI-authenticated key exchange algorithms using the more fashionable curve25519-sha256, [email protected], ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521 elliptic curve groups?

[pseudometric]

Has anyone already amended RFC 4462 to specify GSSAPI-authenticated key exchange algorithms using the more fashionable curve25519-sha256, [email protected], ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521 elliptic curve groups?

@mgkuhn — Yes; there’s an active I-D addressing this as well as updating other aspects of SSH key exchange: Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)

[mgkuhn]

PuTTY now implements this in its latest snapshot and has a nice explanation of the advantages of GSSAPI-based key exchange in its documentation:

"The advantage of doing GSSAPI authentication as part of the SSH key exchange is apparent when you are using credential delegation. The SSH key exchange can be repeated later in the session, and this allows your Kerberos V5 credentials (which are typically short-lived) to be automatically re-delegated to the server when they are refreshed on the client. (This feature is commonly referred to as ‘cascading credentials’.)

If your server doesn't support GSSAPI key exchange, it may still support GSSAPI in the SSH user authentication phase. This will still let you log in using your Kerberos credentials, but will only allow you to delegate the credentials that are active at the beginning of the session; they can't be refreshed automatically later, in a long-running session.

Another effect of GSSAPI key exchange is that it replaces the usual SSH mechanism of permanent host keys. So if you use this method, then you won't be asked any interactive questions about whether to accept the server's host key. Instead, the Kerberos exchange will verify the identity of the host you connect to, at the same time as verifying your identity to it."

[coztoolkit]

Thanks for mentioning this. It's good to see that this was finally implemented in the PuTTY base.

Yes, the elimination of host key verification is a very important side effect.

[mgkuhn]

Perhaps worth linking here some more information from Simon Wilkinson about his patches:
http://blog.inf.ed.ac.uk/sxw/2009/07/26/gssapi-key-exchange-for-openssh-52p1/
http://blog.inf.ed.ac.uk/sxw/2010/01/24/gssapi-key-exchange-for-openssh-5-3p1/
https://github.com/SimonWilkinson/gss-openssh/blob/master/ChangeLog.gssapi
https://bugzilla.mindrot.org/show_bug.cgi?id=1242
The bugzilla link is interesting: Damien Miller explains there why the OpenSSH maintainers never merged these patches, namely “a) we don't trust GSSAPI implementations that much and b) we don't like adding new KEX since they are pre-auth attack surface”. I suspect neither of these reasons would be significant for Microsoft, as they evidently do trust their own GSSAPI implementation (SSPI) at many other places. Simon's patches seem widely used in Linux distributions, but deactivated by default.

[joachimlindenberg]

Is this enhancement request still alive or already dead?

[CJHarmath]

from readme

As of Nov 1st 2016, active development on "Windows for OpenSSH" is being done in https://github.com/PowerShell/openssh-portable.