TL;DR: please try the patch out and report if it causes "Did not receive identification string" log messages. I believe it does not. Josh Soref writes: > Has anyone checked to make sure that this won't upset sshguard? [1] > > Offhand, it looks like it will [2][3]. I haven't checked. And at first sight it looks like it could trip sshguard. But looking a bit more into it, the occurence of this event looks really improbable, as in "Nah, this can't happen". To get the "Did not receive identification string" (DNRIS) at least two TCP connections must have completed the three way handshake. Connections that are initiated but do not run through the full SYN, SYN+ACK, ACK process will not trigger the DNRIS log message (I have not actually checked, this is my reading of the code). So the sequence that could trigger DNRIS logging is: 1. client OS receive SYN+ACK for socket A and replies with ACK, 2. client OS receive SYN+ACK for socket B and replies with ACK, 3. client SSH notices that socket A has successfully connected and closes socket B. Client OS sends FIN for socket B, 4. server OS receives FIN for socket B, SSH wakes from accept and logs DNRIS. Note that the time between step 1 and step 3 is very short because the client is waiting for the SYN+ACK and will promptly close socket B before socket B receives SYN+ACK. What usually happens is: 1. client OS receive SYN+ACK for socket A and replies with ACK, 2. client SSH notices that socket A has successfully connected and closes socket B. 3. client OS receive SYN+ACK for socket B which is closed and replies with RST, 4. server receives RST for socket B and just forgets about it. So most of the time the client will close socket B quickly enough to not cause the DNRIS message. Think processor speed versus network speed. My guess is that the time between receiving a SYN+ACK and closing outstanding sockets is too small to be a practical problem. Of course it would be better to try it out with sshguard and see what reality says. I initially thought that happy eyeballs should not come as a configurable option, but maybe? Kim Minh. > [1] https://www.sshguard.net/ > [2] https://bitbucket.org/sshguard/sshguard/src/2ed7e0aee18b7271daab92d5335c14e04bb2cc89/src/parser/attacks.txt?at=master&fileviewer=file-view-default#attacks.txt-9 > [3] https://bitbucket.org/sshguard/sshguard/src/2ed7e0aee18b7271daab92d5335c14e04bb2cc89/src/parser/attacks.txt?at=master&fileviewer=file-view-default#attacks.txt-10 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
