☰

kex_exchange_identification: lesen: Verbindung vom Peer zurückgesetzt. Verbindung funktioniert auf anderem NIC/Subnetz

tag-icon • tag-icon networking ssh openssh
kex_exchange_identification: lesen: Verbindung vom Peer zurückgesetzt. Verbindung funktioniert auf anderem NIC/Subnetz

Ich habe eine VM (CentOS7) neu installiert und jetzt bekomme ich diesen Fehler. Die VM hat zwei Adapter, die sich in unterschiedlichen Subnetzen befinden.
Lustigerweisessh funktionierte in einem Subnetz einwandfreinachdem die erwartete MITM-Warnung behoben wurde.

ssh -v zeigt:

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

ich habe es versucht

  • Neustart
  • Entfernen der Datei known_hosts
  • /etc/ssh/ssh_config auf dem Client geprüft (keine Abweichung von der Version des Betreuers)
  • /etc/ssh/sshd_config auf dem Server geprüft (keine Abweichung von der Version des Betreuers)
  • Firewall stoppen
  • Berechtigungen für .ssh/ und authorized_keys geprüft
  • Blacklist und Whitelist geprüft (nichts da, nur Kommentare) (hosts.deny|hosts.allow)

Ich bin nicht sicher, ob es relevant ist, aber der Client läuft unter Arch Linux

Also, noch einmal zur Klarstellung:
Der Server hat zwei IP-Adressen, 172.xxx und 192.xxx. SSH funktioniert für 172.xxx, aber nicht für 192.xxx.

Antwort1

Für mich klingt das nach einem Routing-Problem oder einem Problem mit den Netzmasken. Ich habe Fälle mit einer ähnlichen Konfiguration gesehen, in denen der Netzwerkstapel versuchte, die falsche Schnittstelle für ausgehende Pakete zu verwenden, d. h. wo ausgehende Pakete fürbeideSubnetze wurden über die Schnittstelle für dieErsteSubnetz.

Als erstes sollten Sie testen, ob Sie einen anderen Rechner anpingen können injededer Subnetze aus demServerund umgekehrt. Um den Testprozess weniger fehleranfällig zu machen, sollten Sie dieandereMaschinen (Clients) nur zur NutzungeinsIP-Adresse (sonst könnte der Test aufgrund einer falschen Konfiguration desandereMaschinen, was irreführend wäre).

Als nächstes wäre ein genauer Blick auf die Ausgabe route -nauf dem Server und auf den Clients nötig. Vielleicht zeigt das schon die Ursache des Problems. Könnten Sie diese Ausgabe veröffentlichen?

ifconfig -aDarüber hinaus wäre die Ausgabe nützlich (wiederum auf dem Server und auf den Clients) – wir würden schließlich gerne Ihre Netzmasken verstehen.

Wenn Sie diese Ausgaben veröffentlichen, müssen Sie die IP-Adressen meiner Meinung nach nicht verschleiern, solange sie aus dem privaten Bereich stammen. Verschleierung an sich könnte fehleranfällig sein und eine Analyse unmöglich machen.

Wenn Sie sich entscheiden, diese Ausgaben zu veröffentlichen (bearbeiten Sie Ihre Frage bitte entsprechend, anstatt Kommentare dafür zu verwenden, da die Ausgaben lang sein können), werde ich einen Blick darauf werfen und versuchen, herauszufinden, was passiert.

Antwort2

Ich habe diesen Fehler in einer etwas anderen Situation erhalten. In meinem Fall war der SSH-Server überhaupt nicht installiert und das Problem wurde durch die direkte Installation und den Start des Dienstes behoben.

Die Quintessenz ist, dass diese Art von Fehler auftritt, wenn auf dem Port/der IP/der Schnittstelle kein SSH bereitgestellt wird, sei es aufgrund der Installation oder Konfiguration.

verwandte Informationen