kex_exchange_identification: read: Connection reset by peer. Connection works on other NIC/subnet

Question

I re-installed a VM (CentOS7) and now I get this error. The VM has two adapters that are on different subnets.
Funny enough ssh worked fine on one subnet after fixing the expected MITM warning.

ssh -v shows:

OpenSSH_8.0p1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "foreman" port yy
debug2: ssh_connect_direct
debug1: Connecting to foreman [xxx.xxx.xxx.xxx] port yy.
debug1: Connection established.
debug1: identity file /home/sam/.ssh/id_rsa type 0
debug1: identity file /home/sam/.ssh/id_rsa-cert type -1
debug1: identity file /home/sam/.ssh/id_dsa type -1
debug1: identity file /home/sam/.ssh/id_dsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ecdsa type -1
debug1: identity file /home/sam/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ed25519 type -1
debug1: identity file /home/sam/.ssh/id_ed25519-cert type -1
debug1: identity file /home/sam/.ssh/id_xmss type -1
debug1: identity file /home/sam/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
kex_exchange_identification: read: Connection reset by peer

I've tried

Rebooting
removing the known_hosts file
checked /etc/ssh/ssh_config on the client (no deviation from maintainer version)
checked /etc/ssh/sshd_config on the server (no deviation from maintainer version)
stopping the firewalld
checked permissions on .ssh/ and authorized_keys
checked blacklist and whitelist (nothing there, only comments) (hosts.deny|hosts.allow)

I'm not sure if it's relevant, but the client is running arch linux

So, again to clarify
The server has two ip addresses 172.x.x.x and 192.x.x.x
ssh works for 172.x.x.x but does not for 192.x.x.x

Binarus · Answer

To me, that sounds like a routing problem or a problem with the netmasks. I have seen cases with a similar configuration, where the network stack tried to use the wrong interface for outgoing packets, i.e. where outgoing packets for both subnets were routed over the interface for the first subnet.

So the first thing to test is whether you can ping another machine in each of the subnets from the server, and vice versa. To make the testing process less error prone, you should configure the other machines (clients) to use only one IP address (otherwise, the test could fail because of wrong configuration of the other machines, which would be misleading).

The next thing would be a deep look into the output of route -n on the server and on the clients. Perhaps that already shows the cause of the problem. Would you mind publishing that output?

Furthermore, the output of ifconfig -a would be useful (again on the server and on the clients) - we'd eventually like to understand your netmasks.

When publishing those outputs, I think you don't need to obfuscate the IP addresses as long as they are from the private range. Obfuscating per se might be error prone, making analysis impossible.

If you decide to publish those outputs (please edit your question accordingly instead of using comments for that, because that outputs may be long), I'll have a look at it and try to find out what is happening.

kex_exchange_identification: read: Connection reset by peer. Connection works on other NIC/subnet

One Answer

Add your own answers!

Ask a Question