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

>> If you mean the user-authentication sig, I'm not getting to the
>> point of sending a sig.  [...]
> Ah, that may be the issue, I never bother with [...] but, if the
> server asks for publickey auth, perform publickey auth.  See what
> happens when you just perform the auth in one step rather than
> feeding things in in bits and pieces over multiple messages.

I think moussh is not capable of that.

But it shouldn't need to be.  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.  The client "MAY send
the signature directly without first verifying whether the key is
acceptable", but, as I read the spec, it is out of spec for a server to
require that.

Not to say that gitlab isn't out of spec in that regard, of course, but
if so it definitely is out of spec.  Also, nisse@ says that gitlab
drops the connection when the signature _is_ included right away.  I
see the same when it's not.  You didn't specifically say, but you did
say that you were "doing the same thing" as nisse@ and getting a
USERAUTH_FAILURE.  Either way, though, you're doing the same as either
nisse@ or me and getting something different.

You two, what do you send as banner (SSH-2.0-what?)?  I'm wondering if
gitlab was stupid enough to reject solely based on the client's claimed
implementation.  It happens over HTTP; as broken as it would be, it
wouldn't surprise me to see some half-competent implementation doing it
for SSH as well.  I've seen explicit recommendations for differential
behaviour based on the peer implementation for bug workarounds; a
sloppy implementation of that, not tested against anything but OpenSSH
because everyone _knows_ that's all anyone ever uses[%], could lead to
this.

[%] In the last month or two, I've run into at least two SMTP
implementations that ignore a specification that any client-side
timeout at a particular point SHOULD be at least five minutes, timing
out after one minute, with their admins refusing to bring it in line
with the spec.  Not because they think they have something important
enough to ignore the SHOULD for, but simply because they haven't had
reports of trouble interoperating with anyone else - it seems that
today's net considers protocol specs mere suggestions.  This is a MUST
rather than SHOULD, but it still wouldn't surprise me for gitlab to not
care what the spec says.  (And that it wouldn't is depressing.)

Also,

>> If I instead send a SSH_MSG_USERAUTH_REQUEST with method "none" (to
>> query for supported methods), I get a proper
>> SSH_MSG_USERAUTH_FAILURE in response, listing "publickey" as
>> authentications that can continue.

> This is a known bug in some implementations,

How is that a bug?  That's exactly what it should be doing (assuming of
course that publickey auth can indeed continue), is it not?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B