ssh detiene la conexión en "debug1: SSH2_MSG_KEXINIT enviado"

He cambiado el número de puerto ssh desde 22 a 2222 El establecimiento de la comunicación previa por defecto ssh puerto 22 es bien He mapeado el NAT en el router correctamentessh detiene la conexión en "debug1: SSH2_MSG_KEXINIT enviado"

Cuando intento depurarlo

ssh -v -p2222 www.example.com

consigo este error colgando

debug1: SSH2_MSG_KEXINIT

A continuación se muestra todo el registro de depuración

[email protected]:~$ ssh -v -p2222 www.example.com 
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: Applying options for * 
debug1: Connecting to www.example.com [100.100.100.100] port 2222. 
debug1: Connection established. 
debug1: identity file /home/bob/.ssh/identity type -1 
debug1: identity file /home/bob/.ssh/id_rsa type -1 
debug1: identity file /home/bob/.ssh/id_dsa type -1 
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2 
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH* 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 
debug1: SSH2_MSG_KEXINIT sent 
Connection closed by 100.100.100.100

Al igual que la conexión se cierran i utiliza gnome-terminal, masilla, SecureCRT en máquinas par de dentro y fuera de la red sigue siendo todo sale el mismo error

Fuente

2010-03-10 jo3c

esto sería mejor le preguntó sobre http://unix.stackexchange.com/ o http: // askubuntu. com/ –

SSH2_MSG_KEXINIT no es un error. Simplemente te está diciendo que está comenzando el proceso de intercambio de claves ssh.

Si el otro extremo está cerrando la conexión en ese punto, aparentemente no le gustas por alguna razón :-) ¿Tienes acceso a los registros en el servidor al que te estás conectando? Eso puede tener información sobre por qué la conexión se está cerrando precipitadamente. (tcpwrappers, por ejemplo)

Fuente

2010-03-10 18:29:53

desafortunadamente no, no puedo acceder a los registros: < – jo3c

Tuve ese problema en un contenedor dolador CentOS6.4. Necesario para generar claves: 'ssh-keygen -t rsa -f/etc/ssh/ssh_host_rsa_key' Agregue" UsePAM no "en/etc/ssh/sshd_config. Si no es un problema de seguridad, "PermitRootLogin yes". – jamshid

Tuve el mismo problema, sshd se confundió cuando cambié el puerto en sshd_config y reinicié el servicio sshd, cuando finalmente miré los registros del servidor (que parece que no se puede) , sshd se quejaba de que el puerto ya estaba en uso, netstat estuvo de acuerdo, y un ps mostró varias instancias de servicios sshd en ejecución. Los maté y comencé una copia de seguridad de nuevo, y pude conectarme. Juro que traté de reiniciar para solucionar el problema, pero supongo que no, porque eso probablemente lo habría solucionado.

Para abreviar, el sshd que debería estar escuchando en el puerto 2222 para autenticarse no es el que realmente escucha, otro proceso de sshd sí lo es. Si tienes el mismo problema que yo.

Fuente

2010-12-21 23:58:27 Thabo

Tuve este problema y lo resolví configurando el MTU en el enrutador/firewall de destino y en el host de destino al mismo que el host de origen (1500).

Fuente

2011-04-02 18:09:45 ecdpalma

Lo mismo aquí - MTU era 9000 en ambos lados, pero el cambio entre ellos estaba mal configurado. Puede probar el problema utilizando 'ping' con paquetes de tamaño hasta la MTU definida. – Marki555

¡Guau! Nunca hubiera adivinado esto, pero aterrizó en esto después de un rastro de wireshark. Gran captura. – Sonny

Esto parece haber resuelto mi problema también.Uso Tunnelblick para mi VPN, y una vez que configuro "Ejecutar la prueba de tamaño máximo de MTU después de conectarme" en los detalles de la VPN, SSH estaba bien de nuevo. –

Me acaba de ocurrir esto en un host XEN. Había duplicado este host de otro, y como es práctica común, eliminé las claves de host en/etc/ssh después de hacer esto, pensando que se generarían nuevas más tarde. Pero esto nunca sucedió, y sshd comenzó felizmente sin claves de host. Al intentar enviar ssh a este host, se desconectaría después de SSH2_MSG_KEXINIT. Todo lo que tenía que hacer era crear las claves de host, que en la máquina basada en Debian se hace de esta manera:

dpkg-reconfigure openssh-server

Fuente

2013-06-16 21:59:53 izak

En mi opinión, ¡esta es la única respuesta correcta! Pero tal vez solo para mi caso de uso –

Esto resolvió el problema que ocurría en mi contenedor dorador phusion/baseimage (no me preguntes por qué estoy configurando ssh en un instalador de docker - se debe a razones y cosas) – lolski

Este no era exactamente mi problema , pero me acercó más. En mi caso, el problema fue que después de la migración de la clave del host, los permisos no eran correctos. – andi

ssh detiene la conexión en "debug1: SSH2_MSG_KEXINIT enviado"

Respuesta

Cuestiones relacionadas