Re: OpenSSH: cause of random kex_exchange_identification errors?
On Wed, 02 Feb 2022, Vincent Lefevre wrote:
> When I want to connect with SSH (ssh/scp) to some machine, I sometimes
> get errors, either
>
> kex_exchange_identification: Connection closed by remote host
>
> or
>
> kex_exchange_identification: read: Connection reset by peer
That's a very early stage of the initial connection, and your SSH client
just noticed the remote server (or some middle box like a firewall, or
oversubscribed NAT gateway) dropped the TCP connection for whatever
reason.
It will be related to the TCP connection itself, and nothing else. IP
protocol family/address/port, or something in the TCP path misbehaving.
The most common reason is that the remote server disliked your IP
address and/or port due to /etc/hosts.allow/deny, firewalling, or
something in sshd_config. Ensure you check both IPv4 and IPv6.
> The admin of the machine could see nothing particular in the logs.
> He eventually modified the MaxStartups value, but this did not
> solve the issue (but AFAIK, if this were the cause, there would
> have been something about it in the logs). The machine has enough
> available memory.
>
> Any idea about the possible cause of these random errors?
The debugging needs to be done either in the server side, or on *both*
sides.
If you're using socket-forwarding stuff in the client side, check that.
This is exceedingly rare nowadays, so I doubt it. Stuff like SOCKS4 or
SOCKS5 TCP proxies.
Find what is actually listening on the TCP socket server-side, it might
not be sshd (interposers like systemd socket activation, xinetd/inetd,
etc). The logs/access control you need to look at server-side might not
be SSHD's in that case.
If it is sshd, ensure it is actually logging all you need, and carefully
study the logs.
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...
But get the remote admin to re-check server-side /etc/hosts.allow and
deny, sshd_config, etc. with an eye on "what might my SSH client be
using when it failed, and what it might have been using when it worked"
before all that debugging work. Don't forget to consider IPv6, or all
possibly outgoing ranges of IPv4 NAT, if any. It might pay off :-)
--
Henrique Holschuh
Reply to: