Ich verbinde mich seit etwa einem Monat über meinen Mac mit einem Remote-Server. Vor Kurzem habe ich jedoch versucht, eine Verbindung über ssh dylan@MY_IP herzustellen und habe diese Meldung erhalten.
ssh_exchange_identification: read: Connection reset by peer
Ich habe auch einige Diagnoseinformationen erhalten ...
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
Nach einigen Recherchen habe ich Folgendes versucht ...
- Habe meinen Router neugestartet
- Meine "known_hosts"-Datei gelöscht
- Meine "known_hosts"-Datei gelöscht
- Mein DHCP freigegeben und erneuert
- Ich habe es auch von einem anderen Gerät (Windows) mit Putty versucht, ebenfalls mit einem Fehler
Beachten Sie, dass ich keine Änderungen am Server vorgenommen habe, die diese Kommunikation unterbinden.
Ich bin mir auch nicht sicher, ob dies zu Problemen führen würde, aber ich habe sowohl über den Domänennamen als auch über die IP eine Verbindung hergestellt.
Darüber hinaus konnte ich von einer anderen IP-Adresse aus erfolgreich eine Verbindung herstellen.
Ich weiß, dass dies ein großes Problem ist und es viele Ressourcen dazu gibt, aber viele der Lösungen haben nicht funktioniert und ich habe auch keine wirkliche Lösung für irgendjemanden gesehen.
Aktualisieren
Ich habe es auf Protokoll 1 gezwungen. Statt „Verbindung vom Peer zurückgesetzt“ bekomme ich jetzt „Verbindung vom Remote-Host geschlossen“. Das Ausführen mit Debug-Informationen ergab:
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host
Antwort1
So habe ich den Fehler „ssh_exchange_identification: Verbindung vom Remote-Host geschlossen“ beim Verbinden mit einem SSH-Server gelöst.
Ich habe diesen Fehler erhalten, als ich versucht habe, eine Verbindung zu einer eingebetteten Linux-Maschine herzustellen, nachdem ich ein Paket in Root entpackt hatte. Viele Bibliotheksdateien wurden ersetzt, einschließlich libssl.
Versuche zu verbinden:
chetic@ubuntu:~$ ssh -v [email protected]
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer
Beim Googeln schien nur eine Überprüfung von hosts.deny und hosts.allow vorzuschlagen, aber mein Zielcomputer hatte keine solchen Dateien.
Nach einem Neustart (gemäß Karthiks Vorschlag) lief sshd nicht. Ich habe versucht, sshd auf dem Ziel manuell zu starten:
# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f
Ich habe /usr/lib/libssl.a durch die Originalversion ersetzt und sshd gestartet und alles war wieder normal. Das Problem wurde in meinem Fall durch eine falsche Version im Paket verursacht, das ich ursprünglich für Root entpackt hatte.
Antwort2
Ich habe den gleichen Fehler erhalten (aber von jedem Computer, einschließlich dem problematischen Computer über ssh localhost).
Es begann, als ich ein Benutzerprofil migrierte; d. h. nachdem ich Dateien als Root kopiert hatte, führte ich dann Befehle wiechown -R username /Users/username/Destop
jedenfalls bin ich mir absolut nicht sicher, warum der Besitzer von /var/empty in den Benutzernamen geändert wurde, aber sshes muss auf jeden Fall /var/emptyroot gehören (sonst erhalten Sie ssh_exchange_identification: read: Connection reset by peer):
sudo chown root /var/empty
Antwort3
Dies ist kein Problem mit Ihrem lokalen Rechner, sondern ein Problem auf der Serverseite. Es könnteMehrere Faktorendie dieses Problem verursachen:
- Änderungen in der Konfiguration /etc/hosts.allow oder /etc/hosts.deny auf dem Remote-Server.
- Hohe Serverlast.
Wenn ich in der Vergangenheit diese Probleme hatte, habe ich eines von zwei Dingen in der folgenden Reihenfolge getan:
- Ändern Sie /etc/hosts.allow wie im obigen Artikel beschrieben. (und starten Sie den SSH-Server neu.)
- Wenn /etc/hosts.allow bereits den erforderlichen Zustand aufweist, starten Sie einfach den SSH-Server neu (und seien Sie dabei vorsichtig!)
- Wenn der Neustart nicht funktioniert, generieren Sie die Serverschlüssel erneut und starten Sie den SSH-Server neu (das ist riskant, da jeder Benutzer, der sich bei diesem Computer anmeldet, eine Fehlermeldung erhält, dass die Serverschlüssel geändert wurden).
Meistens löst 1 das Problem, aber in einigen Fällen musste ich 2 machen. Ich konnte es nicht herausfindenWarumdas ist der Fall, nur dass es funktioniert hat. Vielleicht hat es etwas mit der Art und Weise zu tun, wie der Schlüssel präsentiert wird, oder vielleicht wurde er irgendwie beschädigt – ich bin nicht sicher. Aber was ich weiß, ist, dass der Fehler ganz und gar etwas mit dem Server zu tun hat und mit der Art und Weise, wie der Handshake abläuft, wenn die SSH-Verbindung eingerichtet wird.
Antwort4
Es handelt sich definitiv um einen Fehler. SSH funktioniert auf einem meiner Rechner, aber nicht auf dem anderen. Ich habe es gelöst. Befolgen Sie diese Schritte.
- Generieren Sie ein Zugriffstoken ohne Ablaufdatum und wählen Sie alle verfügbaren Optionen aus.
- Entfernen Sie die vorhandenen SSH-Schlüssel.
- Klonen Sie das Repo mit https statt mit ssh.
- Verwenden Sie den Benutzernamen, aber anstelle des Kennworts den generierten Zugriffstoken.
Alternativ können Sie Remote auf http setzen, indem Sie diesen Befehl im vorhandenen Repo verwenden und diesen Befehl verwenden: git remote set-url originhttps://gitlab.com/[Benutzername]/[Repo-Name].git