Re: Fixing exchange of host keys in the SSH key exchange

[Mouse <[e-mail]>]

>> (1) Security benefit: although [...]; under reasonable assumptions,
>> if the client has to communicate one or more fingerprints of the
>> server?s host key(s) before KEXINIT, this prevents the situation
>> where the client will present the user with a host key verification
>> dialog, and the user will just click through it.
> It also makes things a lot more painful for the user.

How?  As far as I can see, this affects the user only in that "pick up
the host key on first connect" no longer works.  In particular...

> If you regularly need to SSH into a dozen different devices to
> administer them, it gets even worse.

...I can't see how it affects the user if the client already has a
correct host key for the server.

>> (2) Security benefit: [...]
> This is really just an awkward form of port-knocking.

Awkward?  _Less_ awkward in some respects - significantly easier to set
up in most cases, for example, with no need for anything client-side
beyond a client that knows the extension.  But weaker in other
respects; for example, it reveals the presence of an ssh server to
anyone, even someone who doesn't know the knock (well, probable
presence; nothing says someone can't use port 22 for something else).

>> Server implementations that do not know about this extension, but
>> correctly implement the spec, [...]
> How do we know what percentage of servers do this?

We don't, of course.  But note that the spec does not say that the
_client_ may send text before its version string, only that the
_server_ may.  (Or, at least, if it says that about the client, I
haven't found where.)

Furthermore, just because some implementations are broken (if the
consensus is that that constitutes brokenness, of course) is not a
reason to fail to call them on their brokenness.  I've run into ssh
servers that fall over hard when confronted with clients using the
string@domainname extension mechanism.  Should we stop using it as a
result?  No, we should get the relevant servers fixed (and, as an
interim measure for the immediate term, tell clients to not use
extensions when talking with such broken servers).

> It's true that the spec says you should expect other stuff in the
> textual data, but since pretty much everything out there only ever
> sends the SSH ID string, it's quite likely that lots of
> implementations will choke on unexpected extra lines of text.

Well, if the consensus is that the client is allowed to send text
there (if not, this becomes a private protocol change, not suitable for
interoperation use), then my stance is that that's their problem.  My
advice for users dealing with such servers would be "either get the
server fixed or turn off the extension when using it".

> Even in cases where the code does try and handle non-SSH-ID lines,
> the absence of anything that sends them means it's probably never
> been tested.

Then this suggestion has the additional feature that it will smoke out
such bugs!

Hmm, I think I'll give moussh a configuration option to send things
before the ID string, for exactly that reason.

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