ssh_exchange_identification: Verbindung vom Remote-Host geschlossen (ohne Verwendung von hosts.deny)

Question

Ich binnichtmit hosts.allowoder hosts.deny, außerdem funktioniert SSH von meinem Windows-Rechner (derselbe Laptop, andere Festplatte), aber nicht von meinem Linux-Rechner.

ssh -vvv root@host -p portgibt:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

Auf der Windows-Maschine funktioniert alles einwandfrei, ich habe also die Sicherheitsprotokolle geprüft und die Zeilen darin sind identisch, der Server behandelt die beiden unterschiedlichen „Maschinen“ nicht unterschiedlich und sie werden beide über die Public-Key-Authentifizierung zugelassen.

Daraus lässt sich schließen, dass es sich um ein Problem mit meinem lokalen ArchLinux-Laptop handeln muss … aber welches?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Das ist also nicht das Problem...

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Keine Konflikte mit den Firewall-Einstellungen (derzeit).

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Die Berechtigungen scheinen in Ordnung zu sein (dasselbe gilt für den Server). Habe es auch ohne Konfiguration versucht, /etc/ssh/ssh_configmit demselben Ergebnis, abgesehen von einer Menge automatischer Konfiguration im Client, die mit demselben Fehler endet.

Answer 1

Ursprünglich veröffentlicht auf Ask Ubuntu

Wenn Sie „externe“ Faktoren ausgeschlossen haben, können Sie die Fehlerursache normalerweise mit den folgenden Schritten eingrenzen. Dies beantwortet Ihre Frage zwar nicht direkt, kann aber dabei helfen, die Fehlerursache zu ermitteln.

Fehlerbehebungsshd

Was ich in solchen Fällen generell sehr nützlich finde, ist, zu starten, sshdohne es dämonisieren zu lassen. Das Problem in meinem Fall war, dass weder syslognoch auth.logetwas Sinnvolles anzeigte.

Als ich es vom Terminal aus startete, erhielt ich:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Viel besser! Diese Fehlermeldung hat mir gezeigt, was falsch ist, und ich konnte es beheben. Keine der Protokolldateien enthielt diese Ausgabe.

Hinweis:zumindest unter Ubuntu $(which sshd)ist dies die beste Methode, um sshddie Anforderung eines absoluten Pfads zu erfüllen. Andernfalls erhalten Sie den folgenden Fehler: sshd re-exec requires execution with an absolute path. Dies -p 10222führt dazu, dass sshdauf diesem alternativen Port lauscht und die Konfigurationsdatei überschreibt – damit es nicht zu Konflikten mit möglicherweise laufenden sshdInstanzen kommt. Achten Sie darauf, hier einen freien Port auszuwählen.

Zum Schluss: Verbindung zum alternativen Port herstellen ( ssh -p 10222 user@server).

Diese Methode hat mir schon oft dabei geholfen, Probleme zu finden, seien es Authentifizierungsprobleme oder andere. Um eine wirklich ausführliche Ausgabe zu erhalten stdout, verwenden Sie $(which sshd) -Ddddp 10222(beachten Sie den Zusatz dd, um die Ausführlichkeit zu erhöhen). Weitere Informationen zum Debuggen finden Sie unter man sshd.

---

Der Hauptvorteil dieser Methode besteht darin, dass Sie die sshdKonfiguration überprüfen könnenohneSie müssen sshdden Standardport neu starten.Normalerweisedies sollte bestehende SSH-Verbindungen nicht beeinträchtigen, aber ich habe es gesehen. So kann man die Konfigurationsdatei validieren, bevor man - möglicherweise - den Zugriff auf einen Remote-Server sperrt (ich habe das beispielsweise für einige VPS und sogar für physische Server, bei denen ich extra zahlen muss, um Out-of-Band-Zugriff auf die Maschine zu erhalten).

Answer 2

Sie können auch einen Host haben, dessen Speicher so stark fragmentiert ist, dass er einer Seite keinen zusammenhängenden Speicher zuordnen kann, um den Prozess zum Hosten einer SSH-Sitzung aufzuspalten.

In einem solchen Fall können Sie eine der folgenden Meldungen erhalten:

ssh_exchange_identification: read: Connection reset by peer

oder:

Connection closed by aaa.bbb.ccc.ddd

abhängig davon, wie weit der Host kommt, bevor er abbricht.

Wenn Speicherfragmentierung die offensichtliche Ursache ist, besteht die Lösung darin, auf andere Weise auf den Server zuzugreifen und einige der entsprechenden Dienste neu zu starten. Ich habe festgestellt, dass Apache und MySQL bei VMs die Übeltäter sind, da VMs keine Swap-Partition haben. Wenn das nicht klappt, starten Sie den Host neu.

Answer 3

Nur für den Fall, denn mir ist das passiert. Stellen Sie sicher, dass auf dem Host SSHD ausgeführt wird!

Das ist ein dummer Fehler, könnte aber wirklich Ihr Problem sein.

Answer 4

Ich bin auf das ssh_exchange_identification: read: Connection reset by peerProblem in einem Skript gestoßen, das 16 oder mehr SSH-Sitzungen in einer Schleife startet. sshd kann anscheinend nicht mithalten; das Hinzufügen eines kurzen Ruhezustands (offensichtlich einProblemumgehung... :D Downvoter) haben mein Problem gelöst:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done