Soluzione 1:
Cambia l'interfaccia di rete MTU per risolverlo. Questo è un bug per Ubuntu 14.04.
Questo ha funzionato per me:
sudo ip li set mtu 1200 dev wlan0
O
sudo ifconfig wlan0 mtu 1200
ssh non riesce a connettersi all'host VPN - si blocca su 'expecting SSH2_MSG_KEX_ECDH_REPLY'
Soluzione 2:
Stesso identico problema qui per accedere a un server dedicato nel datacenter di online.net.
Non ci sono problemi dopo un riavvio, non è necessario modificare MTU, la connessione ssh funziona per 1-3 settimane, quindi appare esattamente lo stesso bug, blocco su KEXINIT, non è più possibile connettersi al server ssh.
Potrebbe essere una specie di bug sshd, ma è necessariamente innescato da alcune cose di rete che si verificano dopo 1-3 settimane, ho riprodotto questo problema esatto molte volte con molti server diversi su questa rete, alcuni dicono che potrebbe essere correlato a un bug Cisco, possibilmente correlato con alcune opzioni DPI.
Questo problema non si è mai verificato con altri server che gestisco in altri datacenter e che hanno la stessa identica versione di distro, config e sshd .
se non vuoi riavviare ogni 10 giorni perché i firewall del data center (o altre modifiche alla rete) stanno facendo cose strane:
prima connettiti con una di quelle soluzioni alternative lato client :
soluzione alternativa 1, abbassamento dell'MTU lato client locale:
ip li set mtu 1400 dev wlan0
( 1400 dovrebbe essere sufficiente ma puoi provare a usare valori più bassi se necessario )
soluzione alternativa 2, specificando la cifratura scelta per la connessione ssh :
ssh -c [email protected] host
(o prova con qualsiasi altra cifra disponibile)
Entrambe queste soluzioni alternative lato client hanno fatto per me, ho potuto connettermi e risparmiare il mio tempo di attività; ma vuoi correggere questo lato server, per sempre, quindi non devi chiedere a ogni client di modificare localmente il proprio MTU.
Su gentoo ho appena aggiunto :
mtu_eth0="1400"
in /etc/conf.d/net
(la stessa opzione mtu dovrebbe essere disponibile da qualche parte nel file di configurazione della tua rete di distribuzione preferita)
Ho impostato l'mtu a 1400, ma 1460 è probabilmente sufficiente nella maggior parte dei casi.
un'altra soluzione alternativa potrebbe essere quella di utilizzare le seguenti regole di iptables per gestire la frammentazione:
# /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
(ma personalmente non ne avevo bisogno fino ad ora)
si noti inoltre che i sintomi di questo problema possono anche essere:
debug1: SSH2_MSG_KEXINIT sent
non solo
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
modifica marzo 2016 :
-
abbassare l'mtu a 1400 sul server funziona quasi sempre, ma di recente ho avuto il caso in cui l'mtu era già stato abbassato a 1400 sul server e il problema si è ripresentato, e anche il client ha dovuto abbassare l'mtu a 1400.
-
Il problema è apparso anche sui moduli di accesso Web in attesa che la pagina si ricaricasse fino a quando non si diceva "il server ha ripristinato la connessione", risolto anche dopo che il client aveva impostato mtU a 1400.
link correlati :
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
Soluzione 3:
Nel mio caso, non ho il permesso di abbassare la dimensione MTU. E specificare manualmente il cifrario non funziona.
Sono in grado di connettermi dopo aver abbreviato l'elenco dei MAC specificandone uno, ad esempio:
ssh -o MACs=hmac-sha2-256 <HOST>
Soluzione 4:
Ho avuto lo stesso problema dopo aver aggiornato il mio computer client Ubuntu. Ho risolto il mio problema riducendo la dimensione della riga "Ciphers" in /etc/ssh/ssh_config. Funziona anche se specifichi la cifratura nella riga di comando (es:ssh -c [email protected])
Suggerimento da qui:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39
Soluzione 5:
Ho iniziato ad avere questo problema oggi, su Windows (ssh distribuito con Git) e Ubuntu.
Sembra essere un bug su OpenSSH, c'è un problema su LauchPad.
Ha funzionato per me su Windows forzando la cifratura 3des-cbc e la chiave su Ubuntu.