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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I've encountered servers that misbehave â?? crash or something
>> equivalent from the client's point of view - when faced with the
>> string@domainname extension feature.
> I am flummoxed by the existence of such implementations.

So was I!

> Surely, that would not even be compatible with OpenSSH?

I don't know.  I suspect I tried OpenSSH against them, since I can't
imagine why I would have suspected it were DNS-based extensions causing
trouble without "works" and "fails" traces to compare, and OpenSSH is
the most plausible other implementation for me to have had at hand.
But it would have been OpenSSH of that era.  This was relatively long
ago; in particular, it was before 2008-07-03 - that's the oldest moussh
source tree I have at ready hand, and it's got -no-private (see below).

> Have you seen any of these recently?

No, but I haven't had much opportunity to, either.  (They were the SSH
listeners on devices such as switches.)

> Was that perhaps a decade ago, when OpenSSH maybe didn't have a
> KEXINIT full of string@domain algorithms by default?

That timing is about right.  I don't, and didn't, track what OpenSSH
does (resp. is doing), though.

> I do take the stance that a broken implementation is broken, but this
> does not change that I'm usually expected to do something about it,
> and folks want me to work around it so it works.

I sympathize.  Those switches (or whatever they were) are the reason
moussh has -no-private:

     -no-private
             Disables attempts to use private requests and algorithms (any-
             thing using the DNS extensibility mechanism, basically).  This
             should never be needed, but at least one commercial server is
             known to break when faced with such names.  [...]

> I'd like to think our implementation is close to defect-free, but
> chances are someone somewhere was tasked to implement a workaround
> for a bug that existed in our software, even if it had long since
> been fixed.

Probably.  Same goes for moussh, though it's more likely nobody has
cared enough since moussh surely has a much smaller user base.

> We judge our own software based on the next version we're about to
> release; and other people's software based on all versions that
> existed. :)

That is a common problem.  Stance.  Whatever you want to call it. :-)

>> Hmm, I think I'll give moussh a configuration option to send things
>> before the ID string, for exactly that reason.
> That would be amazing.  I could implement it as an option, but unless
> it is on by default, there's no way we'll get feedback.

I'll try to remember to mention it here when I finally get around to
adding it.  So far I've added it to nothing but my TODO list.

> At this point, the most feasible option I see is the type of probing
> you said you don't like: blind connections to random IP addresses to
> produce statistics how often it works or not.

Quite aside from whether it's moral to use others' servers for your own
purposes like that, that isn't going to tell you more than whether they
are willing to talk to you.  If they drop the connection, you will not
be in a position to tell whether it's because they crashed upon seeing
your pre-version text, or they're configured (as mine are) to refuse to
talk to third parties who don't exhibit whatever behaviour they're
configured to look for, or they crashed for an unrelated reason, or
what.  Also, would "fraction of random IP addresses with ssh servers
that don't crash upon seeing $THING" really be useful statistic, even
if were one you could get?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B