Pregunta Problema de acceso SSH: debug1: esperando SSH2_MSG_KEX_DH_GEX_REPLY


Tenemos un servidor XXX ON Amazon EC2.

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

Coloqué mi pubkey en el archivo /.ssh/authorized_keys

Lo divertido es que AYER estaba funcionando muy bien!

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

ssh -vvvv servername

está atascado en

debug1: esperando   SSH2_MSG_KEX_DH_GEX_REPLY

Revisé mi pubkey y está ahí! (¿Cómo lo verifiqué? Le pregunté al otro chico que lo verificara)

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

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

Esto me está matando)))))

Absolutamente extraño.

¡Por favor ayuda!


17
2017-12-08 12:35


origen


Generé NUEVAS claves y almacené un nuevo pubkey ... ¡lo mismo! ¡decir ah! - bakytn
Para tu información, tu problema no tiene nada que ver con la autenticación de la clave de publicación: el intercambio de claves DH (SSH2_MSG_KEX_DH_GEX_REPLY) Sucede mucho antes en la conexión. - grawity
gracias por la información. Por cierto los chicos, el problema se ha resuelto por sí mismo. No hice nada solo intenté iniciar sesión y tuve éxito. hah - bakytn
¿Mala latencia de red? muchas gotas? Es solo un mensaje normal. - Korjavin Ivan
probablemente lo es Ahora no puedo reproducirlo de ninguna manera. Así podría ser de mi lado. - bakytn


Respuestas:


Tuve el mismo problema después de actualizar mi máquina cliente de Ubuntu. Resolví mi problema reduciendo el tamaño de la línea "Ciphers" en / etc / ssh / ssh_config. También funciona si especifica el cypher 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


6
2018-05-23 13:40





Cambia 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 se puede conectar al host VPN: se cuelga en 'esperando SSH2_MSG_KEX_ECDH_REPLY'


17
2018-02-20 08:27



sudo ip li set mtu 1400 dev eno1 Trabajó para mí en Ubuntu 16.04. - Márcio


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

No hay 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, el bloqueo en KEXINIT, ya no es posible conectar el servidor ssh.

Podría ser algún tipo de error sshd, pero es necesariamente desencadenado 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 ocurrió 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 del lado del cliente:

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

ip li set mtu 1400 dev wlan0

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

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

ssh -c aes256-gcm@openssh.com host

(o prueba con otro cypher disponible)

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

En gentoo acabo de añadir:

mtu_eth0="1400"

en /etc/conf.d/net

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

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

otra solución de ayuda podría ser utilizar las siguientes reglas de iptables para administrar la fragmentación:

# / sbin / iptables -I SALIDA -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

# / sbin / ip6tables -I SALIDA -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

(pero personalmente no necesité 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

edición marzo 2016: 

  • bajar el mtu a 1400 en el servidor, la mayoría siempre funciona, pero recientemente tuve el caso de que mtu ya se había reducido a 1400 en el servidor y el problema volvió a aparecer, y el cliente también tuvo que bajar el mtu a 1400.

  • El problema también apareció en los formularios de inicio de sesión web que esperan a que la página se vuelva a cargar hasta que diga "el servidor ha restablecido la conexión", también se corrigió después de que el cliente configuró 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

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


10
2018-03-17 05:31



Esto puede suceder, especialmente cuando tiene una MTU pequeña muy inusual en el extremo del cliente, por ejemplo. desea utilizar openvpn en una red de doble nat. - Dennis Nolte
Utilicé los valores de mtu predeterminados antes de tener este problema, reducir el mtu fue la solución, no el problema. por favor explique su comentario - neofutur


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>

3
2018-05-09 03:56





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

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

Me funcionó en Windows forzando el cifrado 3des-cbc y la clave en Ubuntu.


1
2017-12-16 14:51





Cambiando el KexAlgorithm funcionó para mí y podría ser una opción donde no tiene 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

0
2018-06-29 11:43





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


-1
2018-06-24 19:58





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


-2
2017-07-01 15:15



Qué parece claro? Esta pregunta fue respondida (con una respuesta aceptada) hace más de 4 años. - David Makogon


cmiiw

  • revisa tu permiso ~ / .ssh / authorized_keys, debería ser 600

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


-3
2017-12-08 13:07



los authorized_keys el permiso no tiene nada que ver con el error, ya que el cliente está atascado durante la negación del protocolo anterior. La verificación de los registros del lado del servidor puede ayudar, pero esta línea es más bien un comentario: un voto negativo. - try-catch-finally