Lösung 1:
Ändern Sie die Netzwerkschnittstellen-MTU, um es zu lösen. Dies ist ein Fehler für Ubuntu 14.04.
Das hat bei mir funktioniert:
sudo ip li set mtu 1200 dev wlan0
ODER
sudo ifconfig wlan0 mtu 1200
ssh kann keine Verbindung zum VPN-Host herstellen – hängt bei „expecting SSH2_MSG_KEX_ECDH_REPLY“
Lösung 2:
Genau das gleiche Problem hier, um auf einen dedizierten Server im online.net-Rechenzentrum zuzugreifen.
Es gibt kein Problem nach einem Neustart, keine Notwendigkeit, die MTU zu ändern, die SSH-Verbindung funktioniert für 1-3 Wochen, dann erscheint genau derselbe Fehler, der KEXINIT blockiert, keine Verbindung mehr zum SSH-Server möglich.
Es könnte eine Art sshd-Bug sein, aber es wird notwendigerweise durch einige Netzwerk-Sachen ausgelöst, die nach 1-3 Wochen passieren. Ich habe genau dieses Problem viele Male mit vielen verschiedenen Servern in diesem Netzwerk reproduziert, einige sagen, es könnte mit einem Cisco-Bug zusammenhängen, hängt möglicherweise mit einigen DPI-Optionen zusammen.
Dieses Problem trat nie bei anderen Servern auf, die ich in anderen Rechenzentren verwalte und die genau dieselbe Distribution, Konfiguration und sshd-Version haben.
wenn Sie nicht alle 10 Tage neu starten möchten, weil die Rechenzentrums-Firewalls (oder andere Netzwerkoptimierungen) seltsame Dinge tun:
Stellen Sie zuerst eine Verbindung mit einer dieser clientseitigen Problemumgehungen her:
Problemumgehung 1, Verringern Ihrer lokalen, clientseitigen MTU :
ip li set mtu 1400 dev wlan0
(1400 sollte ausreichen, aber Sie können versuchen, bei Bedarf niedrigere Werte zu verwenden)
Workaround 2, Angabe der gewählten Chiffre für die SSH-Verbindung:
ssh -c [email protected] host
(oder versuchen Sie es mit einer anderen verfügbaren Chiffre )
Diese beiden clientseitigen Problemumgehungen haben es für mich geschafft, ich konnte eine Verbindung herstellen und meine Betriebszeit sparen. aber Sie möchten dies serverseitig für immer beheben, damit Sie nicht jeden Client bitten müssen, seine MTU lokal zu optimieren.
Auf Gentoo habe ich gerade hinzugefügt:
mtu_eth0="1400"
in /etc/conf.d/net
(dieselbe MTU-Option sollte irgendwo in Ihrer bevorzugten Netzwerkkonfigurationsdatei verfügbar sein)
Ich habe die mtu auf 1400 gesetzt, aber 1460 ist wahrscheinlich in den meisten Fällen ausreichend.
Eine weitere hilfreiche Problemumgehung könnte darin bestehen, die folgenden iptables-Regeln zu verwenden, um die Fragmentierung zu verwalten:
# /sbin/iptables -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# /sbin/ip6tables -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
(aber ich persönlich habe das bis jetzt nicht gebraucht)
Beachten Sie auch, dass die Symptome dieses Problems auch sein können:
debug1: SSH2_MSG_KEXINIT sent
nicht nur
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Bearbeiten März 2016 :
-
Das Absenken der MTU auf 1400 auf dem Server funktioniert meistens immer, aber ich hatte kürzlich den Fall, dass die MTU auf dem Server bereits auf 1400 abgesenkt war und das Problem erneut auftrat und der Client die MTU ebenfalls auf 1400 absenken musste.
-
Das Problem trat auch bei Web-Anmeldeformularen auf, die darauf warteten, dass die Seite neu geladen wurde, bis die Meldung „Der Server hat die Verbindung zurückgesetzt“ anzeigte, ebenfalls behoben, nachdem der Client die mtU auf 1400 gesetzt hatte.
Verwandte Links:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085
http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/
https://nowhere.dk/articles/natty-narwhal-problems-connecting-to-servers-behind-cisco-firewalls-using-ssh
https://stackoverflow.com/questions/2419412/ssh-connection-stop-at-debug1-ssh2-msg-kexinit-sent
http://www.1-script.com/forums/ssh/ssh-hang-after-ssh2-msg-kexinit-sent-10616-.htm
http://www.snailbook.com/faq/mtu-mismatch.auto.html
Lösung 3:
In meinem Fall habe ich keine Berechtigung, die MTU-Größe zu verringern. Und die manuelle Angabe der Chiffre funktioniert nicht.
Ich kann mich verbinden, nachdem ich die MAC-Liste gekürzt habe, indem ich eine angegeben habe, z. B.:
ssh -o MACs=hmac-sha2-256 <HOST>
Lösung 4:
Ich hatte das gleiche Problem, nachdem ich meinen Ubuntu-Client-Rechner aktualisiert hatte. Ich habe mein Problem gelöst, indem ich die Größe der Zeile "Ciphers" in /etc/ssh/ssh_config reduziert habe. Es funktioniert auch, wenn Sie die Chiffre in der Befehlszeile angeben (z. B.:ssh -c [email protected])
Tipp von hier:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39
Lösung 5:
Ich habe dieses Problem heute unter Windows (ssh verteilt mit Git) und Ubuntu.
Es scheint ein Fehler auf OpenSSH zu sein, es gibt ein Problem auf LauchPad.
Es hat bei mir unter Windows funktioniert, indem es die 3des-cbc-Verschlüsselung und den Schlüssel unter Ubuntu erzwang.