protocolo - ssh server
parada de conexión ssh en "debug1: SSH2_MSG_KEXINIT enviado" (4)
Cambié el número de puerto ssh de 22 a 2222 La conexión de configuración anterior al puerto 22 de ssh predeterminado está bien He mapeado el NAT en el enrutador correctamente
Cuando intento depurarlo
ssh -v -p2222 www.example.com
Me sale este error colgando
debug1: SSH2_MSG_KEXINIT
A continuación se muestra todo el registro de depuración
bob@server:~$ 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 cierra utilicé gnome-terminal, masilla, securecrt en máquinas de pareja dentro y fuera de la red, todos reciben el mismo error
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)
Simplemente me sucedió 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 tuve que hacer fue crear las claves del host, que en la máquina basada en debian se hace de esta manera:
dpkg-reconfigure openssh-server
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 use, 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 resumir, el sshd que debería estar escuchando en el puerto 2222 para autenticarte no es el que realmente escucha, otro proceso sshd sí lo está. Si tienes el mismo problema que yo.
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).