Allow GSSAPI authentication methods

[jgoguen]

Please add GSSAPI as a supported auth method. This is useful for clients obtaining a Kerberos token and then using that token to authenticate against the SSH server.

[mscdex]

One reason I've been opposed to this is that there is no way to support something like that without requiring a compiler, something I have been trying to avoid. The other reason is that it's not a high priority thing for me personally since I don't use it, so it's low on my TODO list.

However, I wouldn't be opposed to a PR that added support for it via an optionalDependency to whatever Kerberos addon on npm. Then feature detection is used to dynamically add GSSAPI auth mechanisms during handshaking. This way people who don't have a compiler can still use this module just like before.

[quentinmit]

FYI there is a pure-JS implementation of Kerberos/GSSAPI at https://github.com/davidben/webathena/blob/master/dist/gss.js (and the surrounding repo).

The main challenge you'll still have is getting access to the platform's native credentials cache; on most Linuxes it's easy because that's just a file on disk, but Mac and Windows use daemons ala ssh-agent that you would need to talk to.

[GitMensch]

Hm, both with Putty and with OpenSSH I don't need any agent to run when connecting to an OpenSSH server which has Kerberos active, the only thing necessary is that the username is identical to the one used to login to the Windows box. @quentinmit can you please point out where the functions need access to any files? @mscdex I guess you meant a C++ Node extension like https://www.npmjs.com/package/kerberos ? In this case I guess the only thing needed here is a compiler once (and always when you want to update it), then including the binaries (for win-x64 and some older glibc as x64) in the repo + node module and only try to delay-load it when kerberos authentication is requested). Or even make that an additional node module (with a dependency on this one) to only "ship" if requested.

[quentinmit]

@GitMensch Kerberos on Windows is somewhat magic; other platforms use GSSAPI but windows uses SSPI. When you log in with Kerberos tickets in Putty, Putty is making Windows RPC calls to get a service ticket for the server.

On Linux, tickets are by default stored in a file in /tmp. You can see the current location with klist:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1234_XXX
Default principal: quentin@EXAMPLE.COM

Valid starting       Expires              Service principal
09/05/2021 16:39:44  09/06/2021 00:24:55  krbtgt/EXAMPLE.COM@EXAMPLE.COM
09/05/2021 16:39:45  09/06/2021 00:24:55  host/server.example.com@EXAMPLE.COM

I'm not sure if Windows has klist but if it does it should show something to identify the ticket cache as well. On Macs, the default ticket cache location is also an RPC service (but a completely different one from Windows):

$ klist
Credentials cache: API:977D5870-0B5D-4EE7-8F13-0A86399FBF78
        Principal: quentin@EXAMPLE.COM

  Issued                Expires        Principal
Sep  2 20:18:47 2021  >>>Expired<<<  krbtgt/EXAMPLE.COM@EXAMPLE.COM
Sep  2 20:18:48 2021  >>>Expired<<<  host/server.example.com@EXAMPLE.COM

The lowest common denominator for all the platforms is a file cache, so that would be the place to start with Kerberos support. (Or perhaps even just require that the user pass in the correct service key as a parameter.)

[GitMensch]

just require that the user pass in the correct service key as a parameter

That sounds like the most reasonable option; people that use this module can then use whatever is available on the client (a command line parameter, selection, "extension settings" in vscode case, ...) and would remove the "blocked" state from the software that uses this module.

@quentinmit Do you think you could provide some code, too?

[quentinmit]

@GitMensch I think you've misunderstood how Kerberos tickets work. They're time-limited session keys, so while it would be an okay API for the ssh2 package to take a service ticket (but not great because you really need to negotiate which service ticket to use) that's not something that the user could usefully put in any kind of settings file.

I already linked above to a pure-JavaScript implementation of Kerberos + GSSAPI.

[GitMensch]

Thanks for the follow-up, so it isn't just "give me a folder and I can look in there" (that was my understanding).

I already linked above to a pure-JavaScript implementation of Kerberos + GSSAPI.

So what is your suggestion? To merge that into the ssh2 module? To create a separate node module based on this?

[quentinmit]

Thanks for the follow-up, so it isn't just "give me a folder and I can look in there" (that was my understanding).

Kerberos tickets are stored in a ticket cache. Depending on the platform, a "ticket cache" can be stored in several different places. The lowest common denominator is a FILE cache, which is just a single file on disk, but that's not the default on macOS or Windows. Other supported ticket cache locations include DIR (a directory of files), API/KCM (an API service), KEYRING (Linux kernel keyring), MSLSA (Windows kernel keyring), etc. So a very basic implementation could support FILE caches. That wouldn't be ideal (on Windows or macOS users would have to explicitly copy their tickets into a file cache before trying to use ssh2/VSCode), but it would be far better than nothing and probably sufficient for automation use-cases at least.

I already linked above to a pure-JavaScript implementation of Kerberos + GSSAPI.

So what is your suggestion? To merge that into the ssh2 module? To create a separate node module based on this?

I think the best architecture would be to define an API in the ssh2 module for auth methods. See e.g. how the Go ssh library defines the GSSAPIClient interface. Then the "best" implementation of that would be something that links the native code library on your platform, but a separate implementation could be provided that is pure-JavaScript. For the former, it looks like there's a gssapi.js package that could trivially implement the interface. For the latter, the pure-JS Kerberos implementation should probably be turned into its own Node module, perhaps with the corresponding ssh2 auth method being implemented inside the ssh2 package.