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@xxxxxxxxx> 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@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
