RFC 8305 Happy Eyeballs in OpenSSH

[Josh Soref]

The never abort path won't work. Some SSH systems rely on 2FA/OTP, which
means that there isn't any particular thing that can be reused for the two
sessions (passwords/SSH keys).

Unless ssh wanted to offer a way to say "ohai, that's also me, here's
proof, I'm going now". Which, I think is probably what may be required. And
yes, that would essentially involve a server change, probably adding a
magical credential handler designed for this purpose which allows a token
issued within the past 5(?) minutes to be provided which results in logging
a "happy eyeballs successful connection; disconnect".

I'm sorry I haven't given an absolute answer on IPv6, I'm fairly confident
I'm right about the general problem, but enough of my systems don't support
IPv6 that I can't easily test this. I could probably pay AWS or GCE for two
disparate systems, but the time to set this up of fairly prohibitive.

This stuff does matter to me for a few reasons, I'd like to deploy more
IPv6, I've actually hit a number of rough edges involving happy eyeballs
(DNS stack handling of split horizon can result in some really terrible
outcomes -- especially for SSH, and especially with sshguard), and I
contribute to logwatch...

(I think I still have a big patch pending to OpenSSH...)

On Feb 27, 2018 3:18 PM, "Wolfgang S Rupprecht" <
wolfgang.rupprecht at gmail.com> wrote:

>
> >>> TL;DR: please try the patch out and report if it causes "Did not
> receive
> >>> identification string" log messages.  I believe it does not.
>
> Aw crap.  My homegrown anti-dos tool for ssh looks for either DNRIS or
> if logging is verbose enough a connection that didn't result in a
> login.  I give the attacker a few tries and whitelist any successful
> candidate so I should be ok, but things are getting a bit riskier.
>
> I'm a big fan of happy eyeballs in general so I hope there is some way
> to allow happy eyeballs and still stop bots from repeatedly knocking on
> the door wasting cpu time.  Simplest would be to never abort the extra
> happy eyeballs before actually logging in or the normal ssh connection
> timeout.  There may be other ways to accomplish the same thing.
>
> -wolfgang
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>