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

  • 1
    Does the server have an /etc/hosts.deny file? – user1686 Jul 24 '19 at 8:33
  • Yes, I did (I was still editing my post. You were really quick ;-) – oneindelijk Jul 24 '19 at 8:36
  • What in your /var/log/auth.log file after trying to establish a connection? Also could you share your sshd_config file if possible? I'm assuming nothing sensitive is in there. – Arca Artem Jun 1 at 20:20
  • Here's a sample: Jun 2 09:35:11 mxa sshd[24699]: Accepted publickey for myuser from X.X.X.X port 12345 ssh2: RSA SHA256:XXXXXXXXXXXXXXXXXXXX Jun 2 09:35:11 mxa sshd[24699]: pam_unix(sshd:session): session opened for user myuser by (uid=0) Jun 2 09:35:11 mxa systemd-logind[1058]: New session 7084 of user myuser. Jun 2 09:35:11 mxa systemd: pam_unix(systemd-user:session): session opened for user myuser by (uid=0) – Cyril N. Jun 2 at 9:39
  • @ArcaArtem Everything looks fine. There are a few errors before and after, but related to bots trying to connect to root. – Cyril N. Jun 2 at 9:39

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.

| improve this answer | |
  • Thank you for your message. The issue in my case is that the server are available externally (so I can't post the IP) but also that they can be reached via ping. The ssh command fails, but if I repeat it multiple times, at one point it will succeed (from the first try to sometimes the 5th time). (by doing up, then enter to repeat the command in the term) – Cyril N. Jun 4 at 10:19
  • I didn't understand yet: the server are available externally What does this mean? I thought you have one SSH server with two IP adresses, and other clients connect to it. Connection attempts to IP1 are successful, while connection attempts to IP2 (mostly) fail. Did I get this right? Or is it your SSH server which is available externally? – Binarus Jun 4 at 10:59
  • Yes, sorry. I plugged in on the ticket but it's not my real issue. The problem is the same so I was thinking an answer to it would resolve mine. – Cyril N. Jun 4 at 12:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.