Has anyone checked to make sure that this won't upset sshguard? [1] Offhand, it looks like it will [2][3]. [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 On Sun, Feb 25, 2018 at 2:16 AM, Matthieu Herrb <matthieu at herrb.eu> wrote:> On Fri, Feb 23, 2018 at 12:32:38PM +0000, Kim Minh Kaplan wrote: >> Hello, >> >> I use hosts that are dual stack configured (IPv4 and IPv6) and it >> happens that connectivity through one or the other is broken and >> timeouts. In these case connection to the SSH server can take quite some >> time as ssh waits for the first address to timeout before trying the >> next. >> >> So I gave a stab at implementing RFC 8305. This patch implements part of >> it in sshconnect.c. >> >> * It does not do section 3 (initiation of asynchronous DNS queries, a >> SHOULD). >> * It does not do section 4 (sorting of resolved destination >> addresses). That means it does not do the RFC 6724 address sort >> which is a MUST. The order is still the one from getaddrinfo(3). >> * It implements section 5 (initiation of asynchronous connection >> attempts). It paces the connection attempts 250 milliseconds appart >> as recommended. Once a connection attempt succeeds it cancels all >> other initiated connections and ignores addresses not yet used. >> * It does not implement RFC 8305 for channels.c, that is port >> forwardings do not use it. >> > > Hi, > > I like this. As I'm also running with dual stack machines both at work > and at home, and have sometimes issues with one of the stacks. > > I'm running with this on my OpenBSD machines now. No problem noticed > so far. > -- > Matthieu Herrb > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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
Hi, On Mon, Feb 26, 2018 at 11:32:26AM +0000, Kim Minh Kaplan 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.It depends on absolute RTT to the target. If you stay local ("< 50ms"), the 250ms offset should reliably avoid DNIS logs. If you happen to connect to Australia from Europe ("200+ms RTT") the second SYN might go out before the first handshake is done... but that should be a somewhat rare occurrence. gert -- now what should I write here... Gert Doering - Munich, Germany gert at greenie.muc.de