SSH funktioniert in Putty, aber nicht in Terminal

23

Wenn ich versuche, dies in einem Terminal zu sshen: ssh username@sub.domain.comIch erhalte die folgende Fehlermeldung:
Connection closed by 69.163.227.82

Wenn ich Putty verwende, kann ich eine Verbindung zum Server herstellen. Warum passiert das und wie kann ich das in einem Terminal zum Laufen bringen?

ssh -v Benutzername@domain.com

OpenSSH_6.0p1 (CentrifyDC build 5.1.0-472) (CentrifyDC build 5.1.0-472), OpenSSL 0.9.8w 23 Apr 2012
debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to sub.domain.com [69.163.227.82] port 22.
debug1: Connection established.
debug1: identity file /home/ryannaddy/.ssh/id_rsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 69.163.227.82
linux  ssh  terminal  putty 
— Geh von meinem Rasen runter
quelle
Was ssh -v username@sub.domain.comzeigt?
— James Sneeringer
Ich habe die Hauptfrage aktualisiert. Auch der Server sollte nach einem Passwort fragen, es sind keine SSH-Schlüssel erforderlich, um sich anzumelden.
— Holen Sie sich von meinem Rasen
Haben Sie die Standardeinstellungen in PuTTY geändert?
— Kruug
Hast du es auch versucht user@domain.com? Lass das aus sub.
— Kruug
1
Sie verwenden Centrifys OpenSSH-Build, was bedeutet, dass Ihr System AD-integriert ist. Active Directory verwendet Kerberos, und OpenSSH beschwert sich, dass das Kerberos-KDC nicht gefunden werden kann. Wie /etc/krb5.confsiehst du aus?
— James Sneeringer

Antworten:

23

Die Lösung wurde für mich über die folgende URL gefunden: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Es macht sogar eine ziemlich gute Arbeit zu erklären, was los ist.

Letztendlich habe ich Folgendes zu / etc / ssh / ssh_config hinzugefügt:

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

Weder Ciphers noch HostKeyAlgorithms arbeiteten für sich alleine, ziemlich sicher, dass MACs mich überfordert haben, um dies zum Laufen zu bringen, aber ich kann nicht sicher sein, dass ich viele Stunden darauf verwendet habe, dies zu lösen. Ich hoffe das kann wenigstens jemand anderem helfen.

Bearbeiten: Dies behebt (manchmal) das Problem, aber wahrscheinlich nicht in der von Ihnen gewünschten Weise. - JCWENGER

Diese Einstellungen scheinen (als Nebeneffekt) die Art und Weise zu ändern, wie der ssh-Client Pakete sendet, und bewirken, dass er kleinere Pakete sendet. Dies behebt das Problem nicht. Manchmal wird das eigentliche Problem (MTU-Fragmentierung, die mit dummen Firewall-Regelimplementierungen interagiert) nicht ausgelöst.

Die richtige Lösung besteht darin, eine MTU festzulegen, die von Ende zu Ende funktioniert.

Die MTU manuell auf einen kleineren Wert einstellen zu müssen, um sicherzustellen, dass keine Fragmentierung auftritt, ist nicht sauberer (wir sollten als Benutzer keine Schritte unternehmen müssen, um Problemen zu begegnen, die von unseren Netzwerkteams verursacht werden) ... aber es wird zumindest direkt damit umgegangen die eigentliche Ursache auf zuverlässige und nachweisbare Weise, anstatt die Verschlüsselungseinstellungen von SSH so zu verfälschen, dass sie beim Ausrichten der Sterne zufällig keine großen Pakete erzeugt.

Außerdem ist SSH nicht das einzige, was große Pakete erzeugt. Das Einstellen von MTU verhindert, dass das Gleiche auch bei anderen Protokollen passiert.

— mattw
quelle
5
danke, in meinem Fall hat nur die letzte Zeile MACs hmac-md5,hmac-sha1,hmac-ripemd160gereicht
— Tombart
Ich hatte ein Problem mit Github - Git Pull / Git Push - nichts ist passiert. Versuchte ssh -T -v git@github.com und bekam den gleichen Fehler. Benutzt dies, um es zu lösen. Vielen Dank!
— Jason
Ich hatte ein ähnliches Problem und habe diese Lösung ausprobiert. Ein Nebeneffekt ist, dass jede Verbindung zu einem bekannten Host eine Änderung des Hostschlüssels beschuldigen würde.
— lfagundes
Alle diese Pflaster behandeln das Symptom und nicht die Ursache. Das Verringern der Chiffriergröße kann möglicherweise die Fragmentierung der MTU verhindern. Dies ist das eigentliche Problem, das im Folgenden von @jagguli angesprochen wird.
— Jcwenger
Das Hinzufügen der Zeile "HostKeyAlgorithms ssh-rsa, ssh-dss" in / etc / ssh / ssh_config behebt das Problem, dass kein SSH in ein Zyxel-Modem möglich ist. Alle anderen Zeilen in der obigen Tetbox waren bereits auf meinem Computer vorhanden. Danke für den Tipp!
— Jeff Wright
5

Dies behebt das MTU-Problem, ohne dass ein Wert fest codiert werden muss. Es behebt das Problem für ssh und jedes andere davon betroffene Protokoll. Als root führen Sie folgendes aus:

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

Sie können hier und hier mehr über das Problem und die Lösung lesen .

— Marwan Alsabbagh
quelle
Erläuterung: "Es hat sich herausgestellt, dass das Kernel / Proc-Dateisystem eine einfache Möglichkeit zum Aktivieren und Deaktivieren der TCP-MTU-Prüfung bietet, indem ein Wert in der Datei / proc / sys / net / ipv4 / tcp_mtu_probing geändert wird. Der Wert 0 ist deaktiviert ; 1 = aktiviert, wenn ein Black Hole Router erkannt wird; 2 = immer aktiviert. "
— Jorj
1

Habe einige gesucht und folgenden Vorschlag hier gefunden :

Stellen Sie sicher, dass die folgende Zeile in Ihrer / etc / ssh / ssh_config (NICHT sshd_config) NICHT auskommentiert ist:

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

Sie können auch versuchen, diese Datei auf den Standardwert zurückzusetzen und es erneut zu versuchen, dh openssh-clientIIRC zu deinstallieren und den Namen des Pakets neu zu installieren.

— LawrenceC
quelle
Das hat das Problem nicht behoben :(
— meinem Rasen aus
1

Ich konnte dieses Problem lösen, indem ich die Verwendung von IPv4 erzwang

ssh -4 username@host.xyz

Da ich auf einem Mac bin, weiß ich nicht, wie die MTU-Einstellungen hier sind oder wie sie geändert werden können, dachte aber, dass andere davon profitieren könnten.

— Bruno Kim
quelle
Diese Option zwingt ssh, nur IP4 zu verwenden. Ich bin auch auf dem Mac und es hat mein Problem NICHT gelöst.
— Jorj
0

Ich hatte dieses Problem heute unter Windows (ssh wird mit Git ausgeliefert) und Ubuntu.

Es scheint ein Fehler in OpenSSH zu sein, es gibt ein Problem in LauchPad .

Es funktionierte für mich unter Windows und erzwang die 3des-cbc-Verschlüsselung und den Schlüssel unter Ubuntu.

— LawfulHacker
quelle
0

Ein bisschen nekrotisch hier, aber ich bin auf OpenSSH_7.8p1 unter Linux gestoßen. Die Einführung der DSCP-Kennzeichnung in den jüngsten Versionen von OpenSSH scheint in VMware NAT auf dem Vormarsch zu sein (Bridged Networking wurde in den folgenden Links als in Ordnung erwähnt).

Sie können dies vorerst umgehen, indem Sie Folgendes zu / etc / ssh / ssh_config hinzufügen / setzen :

IPQoS lowdelay throughput

Zusätzliche Faktoren wären, dass PuTTY (oder andere unterschiedliche SSH-Clients) das Problem möglicherweise nicht auf demselben Host antreffen und dass Ihre MTU dies bis jetzt überprüft. dh:

ping -M do -s 1472 your-ssh-server

Diese Posts waren von besonderer Hilfsbereitschaft und brachten mich dorthin, wo ich sein musste:

https://groups.google.com/forum/#!topic/opensshunixdev/5FK67SCpPg8 https://groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A

— Kachunkachunk
quelle
-2

ssh -c aes256-ctr funktioniert gut;

— Udara
quelle
Warum glauben Sie, dass dieser Befehl das Problem lösen wird?
— Scott
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.