How to set preferred Kerberos/GSSAPI library in ssh config file? - visual-studio-code

Question

I can connect to a remote host using Kerberos in PuTTY on Windows 10, but I cannot do the same thing in VS Code.
In PuTTY, there is a setting (see below) that specifies the order of GSSAPI libraries:
Since this answer states that Windows "has two Kerberos libraries (MIT KfW & Windows SSPI)", I suspect that VS Code is not defaulting to the correct, MIT Kerberos GSSAPI64.DLL library.
But I can't seem to find any answers online that shows how to specify the preference or order of such libraries in my ssh config file.
Any suggestions are welcome! Thanks in advance.

Answer 1

There is no way to do that.
When VSCode makes an SSH connection, it normally uses the ssh.exe program from OpenSSH rather than using PuTTY.
PuTTY has been deliberately written to load the libraries on the fly (to avoid the .exe having any hard dependencies), so its ability to configure the library paths is there "for free". That's not the case for OpenSSH, however, or even most other Kerberos-using programs – ssh.exe is "hard" linked to one specific library at compile time; it can dynamically load PKCS#11 backends but hasn't been programmed to dynamically load GSSAPI backends.
In addition, Windows SSPI actually provides a different API from that of GSSAPI – the core concepts and flows are the same, but the function names and prototypes differ quite a bit. Again, PuTTY supports both only because it was deliberately written to do so. Standard OpenSSH would only support GSSAPI, and while Microsoft has patched the "in-box" Win32-OpenSSH to use SSPI, it is still one or the other – you can't really make the Windows ssh.exe load MIT libgssapi instead.
There are several workarounds, though:
You can try installing a different OpenSSH build for Windows that does use GSSAPI from MIT Kerberos; perhaps either Cygwin OpenSSH, or the MSYS OpenSSH that's included with Git could work (if it has GSSAPI support at all).
You can try configuring VSCode to run PuTTY's command-line SSH client plink.exe instead of ssh.exe. This likely won't work for interactive shell sessions, but might be able to handle non-interactive ones (such as VSCode Remoting).
You can try using Windows SSPI, as it does not actually require domain membership to work as a Kerberos client – it's enough to save your Kerberos credentials in Windows:
cmdkey /add:*.example.com /user:sam#EXAMPLE.COM /pass
Note that if the realm is not running Active Directory, you also need to mark it as a "MIT realm" as an Administrator (the presence of a "realm flags" setting – even an empty one – is needed to prevent Windows from doing AD-specific Netlogon probes):
ksetup /addrealmflags EXAMPLE.COM TcpSupported
With the password stored, enabling GSSAPIAuthentication yes in your ~.ssh\config will allow Windows OpenSSH (as well as PuTTY with SSPI) to connect using Kerberos to any host matching the specified *.example.com.