Re: Interop lsh and SSH-2.0-GitLab-SSHD

>> 4252 clearly specifies (top of page 9) after describing
>> USERAUTH_REQUEST with no included signature, that the server "MUST
>> respond to this message with either SSH_MSG_USERAUTH_FAILURE or with
>> the following", followed by a description of a
>> SSH_MSG_USERAUTH_PK_OK message.

> Lest the hand of God come down and smite you, for we all know how
> seriously he takes RFCs.

Well, more like, if you don't follow the spec, then you can't really
expect to interoperate.  (Of course, failure to interoperate is exactly
what we're seeing here.)

> Why does the RFC even allow Blackadder Authentication?  The only use
> for it I've found so far is confusing servers into letting you in as
> someone you're not by performing the auth in enough bits and pieces
> that the state machine gets confused.

This isn't that much of a mystery.  In the words of 4252,

   Private keys are often stored in an encrypted form at the client
   host, and the user must supply a passphrase before the signature can
   be generated.  Even if they are not, the signing operation involves
   some expensive computation.  To avoid unnecessary processing and user
   interaction, the following message is provided for querying whether
   authentication using the "publickey" method would be acceptable.

This is the major use I see for it: to keep the client from having to
generate signatures for a key that the server can easily and quickly
say "no, I won't accept that key no matter _what_ signature you
provide" - while also reliving it of the responsibility for remembering
which key(s) are worth trying for that server.  For a case such as
mine, where generating a PK signature is an expensive operation
(multiple seconds), this is extremely helpful.

Other clients may be able ot generate signatures fast enough that this
isn't an issue for them; they MAY skip the "is it worth bothering
computing a signature for this key?" query to the server.

Of course, from an information-theoretic point of view, this leaks
information, since it allows unauthenticated connections to determine
which key(s) might work.  A server always has the option of issuing a
USERAUTH_PK_OK challenge for any key and just declining the ones it
doesn't like after getting a signature for them; fortunately for
performance when talking to people like me, that is not usually done.

> I actually had to implement a considerable amount of extra checking
> in my code to make sure this can't happen,

I find that surprising.  A USERAUTH_REQUEST with no signature can be
handled with no state change; just send a USERAUTH_FAILURE or a
USERAUTH_PK_OK, as the case may be, and then forget it ever happened.
If the client is going to send a signature-bearing request, it will
contain all the information necessary to handle it independent of any
previous signatureless USERAUTH_REQUEST - or lack thereof.

>> You two, what do you send as banner (SSH-2.0-what?)?
> Just SSH-2.0-cryptlib, but I doubt gitlab would care about that
> unless, as you point out, it's incorrectly fingerprinting a
> workaround for a bug that isn't there.

I just did a test bannering as "SSH-2.0-cryptlib" (without even the
space), but without any other behavioural changes on my end, and it
didn't make any apparent difference; I still saw the connection drop
approximately 51 milliseconds after sending the USERAUTH_REQUEST with
"publickey" as the method name (and some 25-30 ms of that 51 ms is
simply round-trip time, based on delay from sending data to getting ACK
earlier in the conversation).

Interestingly, the packet ACKing that last packet I sent was the same
packet that carried their FIN; unless their ssh server is closely
coupled to their TCP stack, there was _very_ little delay in userland
between getting that packet and closing the connection.

					Mouse