RFC 8305 Happy Eyeballs in OpenSSH

Kim Minh Kaplan openssh-unix-dev.mindrot.org at ml.kim-minh.com
Mon Feb 26 22:32:26 AEDT 2018


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


More information about the openssh-unix-dev mailing list