>>> 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
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 >
Wolfgang S Rupprecht wrote:> Simplest would be to never abort the extra happy eyeballs before > actually logging in or the normal ssh connection timeout.1. What do dualstack browsers do when the second connection opens? 2. ssh could complete authentication on the second connection and then immediately close the connection - but this would trigger many side effects on the server, and be a nuisance at the very least; consider when a server requires token interaction to login, and having a sliding window with some limited number of logins per day. I personally don't really want the client to open multiple connections when I only specicy one server. //Peter
Browsers don't care about aborted transactions. Generally speaking a plain http/https request isn't seen as a potential attack. On Feb 27, 2018 8:27 PM, "Peter Stuge" <peter at stuge.se> wrote: Wolfgang S Rupprecht wrote:> Simplest would be to never abort the extra happy eyeballs before > actually logging in or the normal ssh connection timeout.1. What do dualstack browsers do when the second connection opens? 2. ssh could complete authentication on the second connection and then immediately close the connection - but this would trigger many side effects on the server, and be a nuisance at the very least; consider when a server requires token interaction to login, and having a sliding window with some limited number of logins per day. I personally don't really want the client to open multiple connections when I only specicy one server. //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Wed, 28 Feb 2018, Peter Stuge wrote:> Wolfgang S Rupprecht wrote: > > Simplest would be to never abort the extra happy eyeballs before > > actually logging in or the normal ssh connection timeout. > > 1. What do dualstack browsers do when the second connection opens? > > 2. ssh could complete authentication on the second connection and > then immediately close the connection - but this would trigger many > side effects on the server, and be a nuisance at the very least; > consider when a server requires token interaction to login, and > having a sliding window with some limited number of logins per day. > > I personally don't really want the client to open multiple > connections when I only specicy one server.IMO opening multiple connection (maybe mediated by a knob) is fine, so long as we do one connection first and stagger subsequent ones with a brief delay. Anti-authentication brute force scripts should probably look for actual auth attempts rather than connections; those are well-mitigated by MaxStartups already... -d
Hi, On Wed, Feb 28, 2018 at 01:26:16AM +0000, Peter Stuge wrote:> Wolfgang S Rupprecht wrote: > > Simplest would be to never abort the extra happy eyeballs before > > actually logging in or the normal ssh connection timeout. > > 1. What do dualstack browsers do when the second connection opens?The moment the first connection succeeds, the second one is aborted (-> RST or FIN, depending how far it got wrt TCP establishment) gert -- now what should I write here... Gert Doering - Munich, Germany gert at greenie.muc.de
Josh Soref writes:> I'm fairly confident > I'm right about the general problem,If "the general problem" you are refering to is that the patch could upset sshguard because of "Did not receive identification string" then you are wrong. Kim Minh.
[sorry for the possible duplicate] I'll try and stop the misconception that is starting to spread around. Wolfgang S Rupprecht wrote:> 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.You should rejoice: the patch will NOT cause DNRIS nor a connection that does not result in a login.> Simplest would be to never abort the extra > happy eyeballs before actually logging in or the normal ssh connection > timeout.It is even simpler: it does NOT establish the connection. Kim Minh.