SSH-Client-Problem: Verbindung durch Peer zurückgesetzt [geschlossen]

7

Ich habe ein wirklich nerviges Problem mit meinem Ubuntu-Laptop.

Ich habe es heute nach dem Upgrade auf Ubuntu 11.04 bemerkt, obwohl ich nicht ganz sicher bin, ob dies die Ursache ist, da ich vor einigen Tagen mit meinen SSH-Tasten gespielt habe.

Das Problem ist, wenn ich versuche, auf einen beliebigen Host zu ssh, erhalte ich die folgende Fehlermeldung:

Read from socket failed: Connection reset by peer

Das Ausführen mit -vvv ergibt die folgende Ausgabe:

OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to hostname [10.0.0.2] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "hostname" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

Meine / etc / ssh / ssh_config:

Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication no
    GSSAPIDelegateCredentials no

Ich kann von jedem anderen Server über ssh eine Verbindung zu meinem Laptop herstellen, und ich kann auch von meinem Laptop aus erfolgreich ssh localhost von meinem Laptop aus.

Ich kann von anderen Laptops aus eine Verbindung zu all diesen anderen Servern herstellen, und in den Protokollen der anderen Server wird nichts über meinen fehlgeschlagenen Versuch angezeigt.

Ich habe versucht, iptables zu stoppen, hat nicht geholfen.

Ich habe verschiedene Tricks ausprobiert, die ich online mit meiner Datei / etc / ssh / ssh_config finden konnte, aber ich konnte das Problem nicht lösen ...

Irgendwelche Ideen?

Bearbeiten: Dies ist das Protokoll von einem der Hosts, zu denen ich eine Verbindung herstellen möchte:

May  1 19:15:23 localhost sshd[2845]: debug1: Forked child 2847.
May  1 19:15:23 localhost sshd[2845]: debug3: send_rexec_state: entering fd = 8 config len 577
May  1 19:15:23 localhost sshd[2845]: debug3: ssh_msg_send: type 0
May  1 19:15:23 localhost sshd[2845]: debug3: send_rexec_state: done
May  1 19:15:23 localhost sshd[2847]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
May  1 19:15:23 localhost sshd[2847]: debug1: inetd sockets after dupping: 3, 3
May  1 19:15:23 localhost sshd[2847]: Connection from 10.0.0.7 port 55747
May  1 19:15:23 localhost sshd[2847]: debug1: Client protocol version 2.0; client software version OpenSSH_5.8p1 Debian-1ubuntu3
May  1 19:15:23 localhost sshd[2847]: debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
May  1 19:15:23 localhost sshd[2847]: debug1: Enabling compatibility mode for protocol 2.0
May  1 19:15:23 localhost sshd[2847]: debug1: Local version string SSH-2.0-OpenSSH_5.3
May  1 19:15:23 localhost sshd[2847]: debug2: fd 3 setting O_NONBLOCK
May  1 19:15:23 localhost sshd[2847]: debug2: Network child is on pid 2848
May  1 19:15:23 localhost sshd[2847]: debug3: preauth child monitor started
May  1 19:15:23 localhost sshd[2847]: debug3: mm_request_receive entering
May  1 19:15:23 localhost sshd[2848]: debug3: privsep user:group 74:74
May  1 19:15:23 localhost sshd[2848]: debug1: permanently_set_uid: 74/74
May  1 19:15:23 localhost sshd[2848]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
May  1 19:15:23 localhost sshd[2848]: debug1: SSH2_MSG_KEXINIT sent
May  1 19:15:23 localhost sshd[2848]: debug3: Wrote 784 bytes for a total of 805
May  1 19:15:23 localhost sshd[2848]: fatal: Read from socket failed: Connection reset by peer
ubuntu  ssh 
— Yonix
quelle
Gibt es eine Chance, eines der SSH-Serverprotokolle zu sehen?
— Hmontoliu
Welches Protokoll? Ich habe nichts geschrieben gesehen, als ich versucht habe, eine Verbindung herzustellen (ls -ltr auf / var / log abgefragt und nichts hat sich nach der fehlgeschlagenen Verbindung geändert)
— yonix
@yonix: man sshd_config; Überprüfen Sie die LogLevel-Einstellung
— hmontoliu
@hmontoliu: Oh ... Gut zu wissen. Leider habe ich keinen Root-Zugriff auf diese Server. Aber ich werde versuchen, dass mir morgen vielleicht jemand dabei hilft.
— Yonix
Was ist die Ausgabe von iptables -L -v?
— Justarobert

Antworten:

9

Das ist in openssh schwer zu debuggen. Es scheint nur von bestimmten Clients zu bestimmten Servern zu kommen.

  1. Ursache? Ich bin nicht zur eigentlichen Ursache gekommen. Mein bestes Ergebnis ist, dass die Verbindungspakete zu groß für den Server sind und die Verbindung zurückgesetzt wird.

  2. Problemumgehungen: Begrenzen Sie die Paketgröße. Zwei Alternativen:

    • Begrenzen Sie die Länge der Verschlüsselungsliste, indem Sie '-c' in der ssh-Befehlszeile verwenden, z. B. '-c aes256-ctr'.
    • Begrenzen Sie die HostKeyAlgorithms-Liste, indem Sie ~ / .ssh / config hinzufügen:

      HostKeyAlgorithms ssh-rsa-cert-v01 @ openssh.com, ssh-dss-cert-v01 @ openssh.com, ssh-rsa-cert-v00 @ openssh.com, ssh-dss-cert-v00 @ openssh.com, ecdsa -sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-rsa, ssh-dss

  3. URLs:

  4. Betroffene Versionen: AFAIK startete mit 5.7p1. Ein Downgrade auf 5.5p1 löst das Problem. Auf Computern, auf denen dieses Problem NICHT auftritt, funktionieren 5.7p1, 5.8p1 jedoch einwandfrei. Daher gehe ich davon aus, dass es sich um einen unschuldigen Bibliotheksaufruf handelt, der auf 5.7p1 zu einer Drittanbieter-Bibliothek hinzugefügt wurde, die nur in bestimmten Umgebungen fehlerhaft ist. Verrückte Annahme zu einem verrückten Käfer.

— Mar_Garina
quelle
— Mar_Garina
Erstaunlicher Kerl! Du hast meinen Arsch gerettet! :)
— yonix
1
Übrigens zeigen die Jungs von openssh-unix-dev Interesse daran, diesen Fehler zu beheben. Das Problem ist, dass bisher niemand ein 100% funktionierendes Rezept für die Reproduktion des Fehlers in anderen Umgebungen gefunden hat.
— Mar_Garina
1

Das hat bei mir funktioniert:

Mein /etc/ssh/ssh_config:

Host *

SendEnv LANG LC_*

HashKnownHosts yes

GSSAPIAuthentication yes

GSSAPIDelegateCredentials no

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

Dies liegt daran, dass die Verbindungspakete für den Server zu groß sind und die Verbindung zurückgesetzt wird. Sie können die Chippers-Konfiguration in /etc/ssh/ssh_config... setzen, also versuchen Sie es einfach, ssh -l username hotnameohne dass Sie -c aes256-ctrmehr brauchen .

— VFix
quelle
-1

Ich habe festgestellt, dass dieser Fehler auftritt, wenn ich eine bestimmte WLAN-Verbindung habe. Als ich zu einem anderen WLAN wechselte, verschwand der Fehler. Seltsam, aber echt: - /

— Jon Kern
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.