Re: More GSSAPI on Windows: user auth hangs?

[Jakub Jelen <jjelen@xxxxxxxxxx>]

On 8/23/21 6:10 PM, Kerrison, Adam wrote:
> I’ve spent a while trying to test the GSSAPI support on Windows and I 
> can’t make it work ☹I’ve attached a simple program which just tries to 
> connect and authenticate with a server. It assumes you have a valid 
> Kerberos configuration and a ticket.
> If I run this on Linux is just works. On Windows, it hangs in 
> ssh_userauth_gssapi(). The program enables packet level logging and on 
> Windows I see this before it hangs:
> [2021/08/23 17:01:39.112369, 4] ssh_socket_pollcallback:  Poll callback 
> on socket 756 (POLLIN ), out buffer 0
> [2021/08/23 17:01:39.112369, 3] ssh_packet_socket_callback:  packet: 
> read type 61 [len=176,padding=15,comp=160,payload=160]
> [2021/08/23 17:01:39.113484, 3] ssh_packet_process:  Dispatching handler 
> for packet type 61
> Packet type 61 -> SSH2_MSG_USERAUTH_GSSAPI_TOKEN
>
> On Linux, I see the same message sequence but immediately followed by:
>
> [2021/08/23 17:05:07.856296, 3] 
> ssh_packet_userauth_gssapi_token_client:  Received 
> SSH_MSG_USERAUTH_GSSAPI_TOKEN
> I think this must be something about how I’ve built libssh but its odd 
> as the first part of the GSSAPI auth definitely works (I see the GSSAPI: 
> sending token message for example). I’d also expect things to crash if 
> the function was missing (i.e. a NULL pointer)
> I’m not holding out a lot of hope that anyone will have a clue about 
> what is going on here but I thought I’d ask anyway …
Hi,
my guess is that on Linux you built libssh with server and on Windows 
without.
The packet number SSH2_MSG_USERAUTH_GSSAPI_TOKEN is shared with 
SSH2_MSG_USERAUTH_INFO_RESPONSE, which is implemented only if built with 
server, which is indeed wrong and should be fixed. See the following 
part of the code:
https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/messages.c#L1018

This would explain the hang, as the packet is correctly accepted, but no 
response is sent to peer.
Feel free to test my theory and propose a fix.

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.