No se puede SSH: debug1: esperando SSH2_MSG_KEX_DH_GEX_REPLY

Tenemos un servidor XXX en Amazon EC2.

SSH se ejecuta en un puerto estándar (22).

Coloqué mi clave pública en el archivo /.ssh/authorized_keys

Lo divertido es que AYER funcionó muy bien.

¡Pero hoy no sé qué pasó! Simplemente no puedo iniciar sesión.

ssh -vvvv nombre del servidor

está atrapado en

debug1: esperando SSH2_MSG_KEX_DH_GEX_REPLY

¡Revisé mi pubkey y está allí! (¿Cómo lo comprobé? Le pedí al otro chico que lo verificara)

y luego usé otra computadora (Windows 7 + masilla) y coloqué mi nueva clave pública. ¿Y qué? ¡Pude iniciar sesión! Y esa es otra computadora con Win7 en la misma LAN que significa que la IP externa es la misma.

Mi clave privada funciona para otros servidores pero no con esto.

¡Por favor ayuda!

Cambie la interfaz de red MTU para resolverlo. Este es un error para ubuntu 14.04.

Esto funcionó para mí:

sudo ip li set mtu 1200 dev wlan0

O

sudo ifconfig wlan0 mtu 1200

ssh no puede conectarse al host VPN: se bloquea en 'esperando SSH2_MSG_KEX_ECDH_REPLY'

El mismo problema exacto aquí para acceder a un servidor dedicado en el centro de datos en línea.net.

No hay ningún problema después de un reinicio, no es necesario cambiar MTU, la conexión ssh funciona durante 1-3 semanas, luego aparece exactamente el mismo error, bloqueando en KEXINIT, no es posible conectar el servidor ssh.

Podría ser algún tipo de error sshd, pero necesariamente se desencadena por algunas cosas de nework que suceden después de 1-3 semanas, reproduje este problema exacto muchas veces con muchos servidores diferentes en esta red, algunos dicen que podría estar relacionado con un error de Cisco, posiblemente relacionado con algunas opciones de DPI.

Ese problema nunca sucedió con otros servidores que administro en otros centros de datos, y que tienen exactamente la misma distribución, configuración y versión sshd.

si no desea reiniciar cada 10 días porque los firewalls del centro de datos (u otros ajustes de red) están haciendo cosas raras:

primero conéctese con una de esas soluciones alternativas del lado del cliente:

solución 1, reduciendo su MTU local del lado del cliente:

ip li set mtu 1400 dev wlan0

(1400 debería ser suficiente, pero puede intentar usar valores más bajos si es necesario)

solución 2, especificando el cifrado elegido para la conexión ssh:

ssh -c aes256-gcm@openssh.com host

(o intente con cualquier otra cifra disponible)

Ambas soluciones alternativas del lado del cliente lo hicieron para mí, podría conectarme y ahorrar mi tiempo de actividad; pero desea solucionar este lado del servidor para siempre, por lo que no tiene que pedir a cada cliente que modifique localmente su MTU.

En gentoo acabo de agregar:

mtu_eth0="1400"

en /etc/conf.d/net

(la misma opción de mtu debería estar disponible en algún lugar de su archivo de configuración de red de distribución preferido)

He configurado el mtu a 1400, pero 1460 es probablemente suficiente en la mayoría de los casos.

Otra solución alternativa podría ser utilizar las siguientes reglas de iptables para gestionar la fragmentación:

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

(pero personalmente no necesitaba este hasta ahora)

También tenga en cuenta que los síntomas de este problema también pueden ser:

debug1: SSH2_MSG_KEXINIT sent

No solo

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

editar marzo 2016:

• bajar el mtu a 1400 en el servidor casi siempre funciona, pero recientemente tuve el caso de que mtu ya estaba bajado a 1400 en el servidor y el problema reapareció, y el cliente también tuvo que bajar mtu a 1400.

• El problema también apareció en los formularios de inicio de sesión web que esperaban que la página se volviera a cargar hasta decir "el servidor ha restablecido la conexión", también solucionado después de que el cliente configurara el mtU en 1400.

  enlaces relacionados :

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

En mi caso, no tengo permiso para reducir el tamaño de MTU. Y especificar manualmente el cifrado no funciona.

Puedo conectarme después de acortar la lista de MAC especificando uno, por ejemplo:

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

Tuve el mismo problema después de actualizar mi máquina cliente Ubuntu. Resolví mi problema reduciendo el tamaño de la línea "Ciphers" en / etc / ssh / ssh_config. También funciona si especifica el cifrado en la línea de comando (por ejemplo: ssh -c username @ hostname)

Consejo desde aquí:

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

Empecé a tener este problema hoy, en Windows (ssh distribuido con Git) y Ubuntu.

Parece ser un error en OpenSSH, hay un problema en LauchPad .

Funcionó para mí en Windows forzando el cifrado 3des-cbc y la clave en Ubuntu.

Cambiar el KexAlgorithm funcionó para mí, y podría ser una opción donde no tienes los derechos del sistema para cambiar la configuración de MTU. Esto también podría ser uno para el equipo de OpenSSH para abordar. p.ej

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

lo resolvimos comentando la línea Ciphers en / etc / ssh / ssh_config

Parece claro que el diálogo de opciones causa un problema, porque alteré el orden en que Putty negocia el intercambio de claves y el problema resuelto.

cmiiw

• verifique su permiso ~ / .ssh / certified_keys, debe ser 600

• marque en on / var / log / secure, / var / log / messages o / var / log / auth