Impossibile SSH: debug1: attesa SSH2_MSG_KEX_DH_GEX_REPLY

Abbiamo un server XXX SU Amazon EC2.

SSH è in esecuzione su una porta standard (22).

Ho inserito la mia pubkey nel file /.ssh/authorized_keys

La cosa divertente è che ieri funzionava alla grande!

Ma oggi non so cosa sia successo! Non riesco ad accedere.

ssh -vvvv nome server

è bloccato

debug1: in attesa di SSH2_MSG_KEX_DH_GEX_REPLY

Ho controllato il mio pubkey ed è lì! (come ho controllato ?? ho chiesto all'altro ragazzo di controllare)

e poi ho usato un altro computer (Windows 7 + stucco) e ho posizionato il mio nuovo pubkey. E cosa? Sono stato in grado di accedere! E questo è un altro computer con Win7 è sulla stessa LAN che menziona che l'IP esterno è lo stesso.

La mia chiave privata funziona per altri server ma non con questo.

Per favore aiuto!

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 in "attesa SSH2_MSG_KEX_ECDH_REPLY"

Stesso problema esatto qui per accedere a un server dedicato nel datacenter online.net.

Non c'è nessun problema dopo un riavvio, non è necessario modificare MTU, la connessione ssh funziona per 1-3 settimane, quindi appare esattamente lo stesso bug, bloccando su KEXINIT, non è più possibile connettere il server ssh.

Potrebbe essere una specie di bug sshd, ma è necessariamente innescato da alcune cose nework 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 data center e che hanno esattamente la stessa versione di distro, config e sshd.

se non si desidera riavviare ogni 10 giorni perché i firewall del datacenter (o altre modifiche di rete) stanno facendo cose strane:

connettersi innanzitutto con una di quelle soluzioni alternative lato client:

soluzione alternativa 1, riducendo l'MTU locale lato client:

ip li set mtu 1400 dev wlan0

(1400 dovrebbe essere sufficiente ma puoi provare a usare valori più bassi se necessario)

soluzione 2, specificando il codice scelto per la connessione ssh:

ssh -c aes256-gcm@openssh.com host

(o prova con un altro codice disponibile)

Entrambe le soluzioni alternative sul lato client mi hanno permesso di connettermi e risparmiare tempo di attività; ma vuoi riparare questo lato server, per sempre, quindi non devi chiedere a tutti i client di modificare localmente il loro 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 rete di distribuzione preferita)

Ho impostato il mtu su 1400, ma 1460 è probabilmente abbastanza 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)

notare 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:

• l'abbassamento del mtu a 1400 sul server funziona quasi sempre, ma recentemente ho avuto il caso in cui mtu era già stato abbassato a 1400 sul server e il problema è riapparso, e anche il client ha dovuto abbassare mtu a 1400.

• Il problema è apparso anche sui moduli di accesso web in attesa che la pagina si ricaricasse fino a quando "il server ha ripristinato la connessione", risolto anche dopo che il client ha impostato mtU su 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

/programming/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

Nel mio caso, non ho il permesso di abbassare la dimensione MTU. E specificare manualmente il codice non funziona.

Sono in grado di connettermi dopo aver abbreviato l'elenco MAC specificandone uno, ad esempio:

ssh -o MACs=hmac-sha2-256 <HOST>

Ho avuto lo stesso problema dopo aver aggiornato la mia macchina client Ubuntu. Ho risolto il mio problema riducendo la dimensione della riga "Ciphers" in / etc / ssh / ssh_config. Funziona anche se si specifica il cifratore nella riga di comando (es: ssh -c username @ hostname)

Suggerimento da qui:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39

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 il codice 3des-cbc e la chiave su Ubuntu.

La modifica di KexAlgorithm ha funzionato per me e potrebbe essere un'opzione in cui non si dispone dei diritti di sistema per modificare le impostazioni MTU. Questo potrebbe anche essere quello a cui deve rivolgersi il personale di OpenSSH. per esempio

ssh -o KexAlgorithms=ecdh-sha2-nistp521 fu@bar.com

lo abbiamo risolto commentando la riga Ciphers su / etc / ssh / ssh_config

Sembra chiaro che la finestra di dialogo delle opzioni causi un problema, perché ho modificato l'ordine in cui Putty negozia lo scambio di chiavi e il problema è stato risolto.

cmiiw

• controlla la tua autorizzazione ~ / .ssh / authorized_keys, dovrebbe essere 600

• controlla su on / var / log / secure, / var / log / messages o / var / log / auth