ssh_exchange_identification: read: Verbindung von Peer zurückgesetzt

106

Ich arbeite unter OS X und versuche, in einen Ubuntu 12.04-Server zu sshen. Ich konnte SSH einspielen - bis plötzlich nichts mehr funktionierte. Ich habe online gelesen, um das -vzu debuggen. Die Ausgabe wird unten gezeigt. Wenn ich in eine andere Box ssh und dann von dieser Box auf den Server ssh kann ich mich einloggen. Ich habe keine Ahnung, wie Sie dieses Problem beheben können, möchte aber lernen.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
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 *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Bisher habe ich (auf Anraten von Message Boards) nach einer Hosts Deny- Datei gesucht - aber auf meinem Computer befindet sich keine solche Datei.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

Ich habe Administratorzugriff auf dem Client-Computer, aber nicht auf dem Server.

ssh

— bernie2436
quelle

Ich würde empfehlen, ein sshdListening an einem alternativen Port mit ausführlicher Ausgabe zu starten und die Ausgabe bereitzustellen, wenn Sie versuchen, eine Verbindung zu ihm herzustellen. $(which sshd) -d -p 23. Wenn Sie dazu nicht in der Lage sind, sind Ihre Optionen ziemlich begrenzt. Am besten ist es, jemanden zu finden, der Administratorrechte auf dem Server hat.

— Patrick

Könnte es sein, dass der Administrator auf dem Server Ihren Zugriff aus irgendeinem Grund eingeschränkt hat? In jedem Fall könnte ich diese Person kontaktieren.

— MDPC

12

Die hosts.deny und hosts.allow - Datei sollte auf dem überprüft werden Server , nicht auf dem Client. Außerdem sollten die Systemprotokolle auf dem Server überprüft werden. Wenn Sie auch keinen Zugriff auf diese haben, können Sie sich an den Serveradministrator wenden, um einen Blick darauf zu werfen.

— ckujau

Hast du eine Lösung dafür gefunden? Was war das Problem?

— MeV

2

War eine hosts.deny Liste, die vom Admin mit einem automatischen Skript gefüllt wurde. Da ich irgendwann mein Passwort vergessen habe, hatte ich einige erfolglose Anmeldeversuche. Damals wurde meine IP auf die Liste hosts.deny gesetzt. Soviel zur Produktivität übereifriger Sicherheit.

— K.-Michael Aye

24

Die plötzliche Änderung kann das Ergebnis einer Änderung in der Konfigurationsdatei der Serverkonfiguration sein. sshdSie können dies jedoch nicht ohne Administratorrechte überprüfen oder ändern. Sie können weiterhin Folgendes versuchen, wenn die Administratoren des Servers (rechtzeitig) nicht erreichbar sind.

In Ihrem Protokoll wird nur die lokale Versionszeichenfolge angezeigt. Sie sollten die sshdauf dem Server und dem Zwischencomputer ausgeführten Versionen überprüfen .

Wenn diese Versionen (vor allem zwischen dem lokalen Rechner und dem Server und weniger zwischen der Zwischen Maschine und dem Server) unterscheiden könnte es einige Verhandlungen Unverträglichkeit sein, dies zuvor geschehen ist in ssh. Früher bestand die Lösung darin, die Einträge Ciphers, HostKeyAlgorithms und / oder MACs entweder in der Befehlszeile ( ssh -c aes256-ctrusw.) oder in Ihrer zu kürzen /etc/ssh/ssh_config.

Sie sollten in den Debug-Informationen (von der Verbindung über das Intermediate zum Server) nach geeigneten Werten als Argument für die Befehlszeile -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsund -m/ MACssuchen. ssh_config ändert sich.

Ich hatte dieses Problem selbst schon eine Weile nicht mehr, aber IIRC als ich es tat, genügte es, die Einstellung von Ciphers und HostKeyAlgorithms manuell zu erzwingen. Danach konnte ich die Serverversion aktualisieren sshdund das Problem verschwand .

— Anthon
quelle

3

In meinem Fall wurde das sshdServerpaket auf eine neuere Version aktualisiert und führt, sshwie Sie sagten, zu Inkompatibilität mit meiner aktuellen Client-Konfiguration. Das Löschen meiner alten sshKonfigurationsdateien hat den Trick getan. Dies sollte die akzeptierte Antwort sein.

— Chakrit

2

@chakrit Wie haben Sie Ihre alten ssh-Konfigurationsdateien gelöscht?

— Jonathan

@ Jonathan Ich habe eine Wiederherstellungsdiskette gemountet, um dies zu tun.

— Chakrit

16

Möglicherweise wurden Sie von fail2banoder gebannt denyhosts. In einem solchen Fall (und um dies auch zu überprüfen) müssen Sie sich von einer anderen IP-Adresse bei Ihrem Server anmelden, z. B. von einem anderen Server oder der Heimverbindung eines Freundes oder von einem WiFi-Hotspot oder Verwendung von SSH mit TOR.

Überprüfen Sie nach dem Anmelden, ob Ihre IP-Adresse tatsächlich in /etc/hosts.deny(auf der Serverseite) angezeigt wird . Wenn ja, dann ist fail2banoder denyhostsmuss dies tatsächlich der Schuldige sein.

Lesen Sie die Antworten auf diese Frage, um zu verhindern denyhosts, dass Ihre Adresse kontinuierlich gesperrt wird. Um fail2banIhre IP mit zu finden und Ihre IP mit iptables -L --line-numberaufzuheben iptables -D <chain> <chain number>, überprüfen Sie die Details auf howtoforge .

Vielleicht möchten Sie Ihre IP - Adresse hinzufügen fail2banund denyhostsweiße Listen (bzw. /etc/fail2ban/jail.conf, Linie ignoreip, und /var/lib/denyhosts/allowed-hostsschafft es , wenn nötig (aber Vorsicht , dass der Weg nach Distribution verschieden sein kann)) , um das Problem zu verhindern , wieder zu geschehen.

— Skippy le Grand Gourou
quelle

9

Auf dem Host - Server, entfernen Sie den ssh pub.key hier zu finden: ~/.ssh/authorized_keysfür Ihren Mac. Dann, tail -f /var/log/auth.logwährend Sie ein anderes Terminal öffnen und erneut versuchen, ssh ssh -v me@server. Wenn Sie zur Eingabe eines Kennworts aufgefordert werden, ist ein Problem mit Ihrem SSH-Schlüssel aufgetreten. Wenn Sie weiterhin die Antwort 'ssh_exchange_identification: read: Connection reset by peer' sehen, sollten Sie in der Lage sein, das Problem anhand des Protokolleintrags in der Datei '/var/log/auth.log' nach Ihrem fehlgeschlagenen Versuch zu identifizieren Einloggen.

Wenn Sie immer noch keine Verbindung herstellen konnten, posten Sie den protokollierten Eintrag aus der Auth-Datei hier und ich werde meine Antwort überarbeiten.

— devnull
quelle

In einigen Fällen muss der SSH-Schlüssel nicht gelöscht werden. Gehen Sie direkt zu tail -f /var/log/auth.log und überprüfen Sie die letzten Versuche.

— Jack Robson

6

Dies kann vorkommen, wenn Sie mehrere Computer mit derselben MAC-Adresse im Netzwerk haben (z. B. wenn Sie eine Kopie eines virtuellen Computers erstellen und vergessen, den MAC zu ändern).

— elCapitano
quelle

4

Ich bekam das wegen der Nameserver meines ISP in /etc/resolv.conf. Diese Nameserver sind häufig überlastet und wenn die Reverse-DNS-Suche fehlschlägt, sshdwird die Verbindung getrennt. Ich habe das Problem mit zuverlässigeren Nameservern gelöst, z 8.8.8.8.

— njahnke
quelle

4

Ich war mit dem gleichen Problem konfrontiert. Ich würde die SSH-Sitzung erfolgreich eröffnen, aber sie würde nach einiger Zeit zurückgesetzt werden. Wenn ich versuchte, Gewinn sofort anzuschließen, würde ich den Fehler "Verbindung zurückgewiesen" erhalten. als ich die Sitzung ausprüfte, erhielt ich diese Mitteilung, als die Verbindung zurückgesetzt wurde

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

Zu diesem Zeitpunkt erkannte ich, dass es einen IP-Adressenkonflikt im Netzwerk gab. Ich habe zu einer anderen Adresse gewechselt und das Problem wurde behoben

— David
quelle

2

Downvotes, was ist los mit der Antwort? Es kann immer noch ein gültiger Fall sein, zu überprüfen, wenn eine Liste durchgegangen wird, nur vielleicht nicht ein allgemeiner unter anderen.

— Pysis

@Pysis: Richtige, hochgeladene Antwort

— Daniel

3

Ihr Protokoll bedeutet, dass die Verbindung serverseitig getrennt wird. Um den Grund herauszufinden, sollten Sie die serverseitigen Protokolle konsultieren. Sie sollten den Grund für die Trennung anzeigen. Sie sollten fast immer in der Lage sein, Protokolle in / var / log / messages zu finden

Ich könnte vermuten, dass der Server den Client als inkompatibel bedroht, als die Verbindung unterbrochen wurde, nachdem der Client die Versionsnummer gesendet hatte.

— gena2x
quelle

3

Ich hatte das gleiche Problem, aber es stellte sich heraus, dass die Ursache anders war: Ich habe einen falschen Port verwendet.

Bei neueren Versionen wird sshder Fehler Connection refusedoder angegeben Bad port.

Bei älteren Versionen ist der angegebene Fehler ssh_exchange_identification: read: Connection reset by peer

Wenn Sie einen solchen Fehler erhalten, prüfen Sie, ob der Port korrekt ist.

— Mugoma J. Okomba
quelle

1

Ich weiß, dass diese Frage alt ist, aber ich wollte einige Ergebnisse mitteilen, die ich hatte. Überprüfen Sie, ob /var/empty/sshdder Server über die entsprechenden Eigentumsrechte und Berechtigungen verfügt.

Wir hatten ein Chef-Skript, das geändert wurde, um einige Verzeichnisberechtigungen zu aktualisieren, aber versehentlich das Verzeichnis unterhalb des beabsichtigten Ziels aktualisiert, den Besitz von / var in einen Anwendungsbenutzer / eine Anwendungsgruppe geändert und die Berechtigungen auf 775 geändert hat.

— Andrew Boerema
quelle

1

Da dies in einer Antwort nicht ausdrücklich erwähnt wurde, kann dieser Fehler auch auftreten, wenn eine netzwerkbasierte Firewall zwischen Ihnen und dem Server beschlossen hat, die Verbindung zu blockieren. Die Firewall hätte feststellen können, dass "zu viele" Verbindungen von der IP-Adresse des OS X-Systems vorhanden waren, und begann, diese zu blockieren. Es gab noch nicht "zu viele" Verbindungen vom anderen System und so war es erlaubt.

Die letzte Nachricht, die Sie vom Server erhalten haben, tritt auf, bevor Sie überhaupt Authentifizierungsversuche starten. Dies schließt eine Vielzahl von Möglichkeiten aus, die Ihr Konto, Ihren Schlüssel oder Ihr Kennwort betreffen.

Beispiele für solche Brute-Force-Richtlinien aus einer zufälligen Auswahl von Anbietern sind:

— Jeff Schaller
quelle