Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre <vincent@vinc17.net>]

On 2022-02-05 18:39:27 -0300, Henrique de Moraes Holschuh wrote:
> If it is sshd, ensure it is actually logging all you need, and carefully
> study the logs.

Nothing interesting in the logs, according to the admins of the server.

> If nothing helps, packet-dump both sides (client and server) and find
> out what sent the TCP RST, as that might give you clues for the "why".
> A middlebox might be doing it...

I eventually did a packet capture on the client side as I was able to
reproduce the problem. When it occurs, I get the following sequence:

Client → Server: [SYN] Seq=0
Server → Client: [SYN, ACK] Seq=0
Client → Server: [ACK] Seq=1
Server → Client: [FIN, ACK] Seq=1
Client → Server: Client: Protocol (SSH-2.0-OpenSSH_9.0p1 Debian-1)
Server → Client: [RST] Seq=2
Client → Server: [FIN, ACK] Seq=33
Server → Client: [RST] Seq=2

So the issue comes from the server, which sends [FIN, ACK] to terminate
the connection. In OpenSSH's sshd.c, this could be due to

                        if (unset_nonblock(*newsock) == -1 ||
                            drop_connection(*newsock, startups) ||
                            pipe(startup_p) == -1) {
                                close(*newsock);
                                continue;
                        }

At least 2 kinds of errors are not logged:

* In unset_nonblock(), a "fcntl(fd, F_SETFL, val) == -1" condition.

* the "pipe(startup_p) == -1" condition.

I'm not sure about drop_connection(), which is related to MaxStartups.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)