Si bien en muchos casos el error ssh_exchange_identification: Connection cerrada por host remoto puede ser causado por problemas relacionados con los archivos de configuración hosts.deny y hosts.allow, hay otras cosas que pueden causar el problema. Si está leyendo esto, es probable que ya haya verificado para asegurarse de que ambos archivos no estuvieran bloqueando su dirección IP para que no intente usar ssh en un servidor remoto.
Suponiendo que este sea el caso, entonces podría estar viendo un problema de dependencia, algo relacionado con la fragmentación de la memoria o incluso un número excesivo de sesiones provenientes de clientes individuales. La buena noticia es que una vez que haya solucionado el problema, no debería volver a ver el error.
Método 1: reparación de dependencias faltantes
Si ha obtenido ssh_exchange_identification: conexión cerrada por error de host remoto solo después de actualizar OpenSSL o glibc, es posible que esté buscando una dependencia faltante. Ejecute sudo lsof -n | grep ssh | grep DEL de la línea de comando en esta situación. Esto le dará una lista de archivos abiertos, luego busque solo los que se eliminaron recientemente relacionados con el demonio ssh.
Si no obtiene nada a cambio, puede intentar reiniciar el demonio o el sistema en sí. Querrá intentar reiniciar si se le arrojaron una serie de errores, aunque puede ignorar con seguridad los relacionados con los mensajes / run / user / 1000 / gvfs, ya que estos son causados por un problema no relacionado que debe hacer con un sistema de archivos virtual.
También puede intentar usar apt-get, pacman o yum para actualizar sus paquetes si sospecha que las dependencias son un problema. Si está en un sistema basado en Debian o Ubuntu, es posible que desee probar sudo apt-get -f upgrade y ver si eso soluciona algún paquete roto con el que podría haber caído.
Método 2: corrección de la fragmentación de la memoria
Si esto no ayudó, es posible que tenga un problema en el lado del host de la ecuación. Los hosts que se ejecutan dentro de una máquina virtual no siempre tienen una partición de intercambio, lo que puede provocar la fragmentación de la memoria. Acceda al host por otros medios, tal vez físicamente si es posible, y luego reinicie cualquier servicio que tenga problemas. MySQL, Apache, nginx y otros servicios similares podrían ser los culpables.
Si bien es posible que no siempre sea posible reiniciar el host, esto puede corregir el problema y podría ser una buena idea si ha estado alternando entre este mensaje de error y uno que devuelve una dirección IP. Tenga en cuenta que si tiene algún tipo de acceso al servidor, puede ejecutar el comando vmstat -s y obtener algunas estadísticas importantes sobre cómo se usa la memoria incluso como un usuario regular en muchos casos.
Método 3: comprobar si hay instancias de ssh adicionales
Salvo esto, verifique si los hosts están tratando de conectarse al servidor. Es posible que haya excedido el número máximo de sesiones ssh sin saberlo. Borre las sesiones anteriores y luego intente volver a conectarse. Una forma fácil de hacerlo es ejecutar el comando who para ver qué procesos de usuario están conectados. Solo debería ver uno o dos usuarios conectados. Si hay varios en paralelo, elimine los procesos de usuario e intente volver a iniciar sesión .
Esto puede suceder si sshd no puede seguir el ritmo de un script que inicia muchas sesiones ssh diferentes en un bucle. Si esto le sucedió alguna vez, agregue el comando sleep 0.3 al ciclo para que el demonio sshd tenga tiempo de mantenerse al día.
Método 4: encontrar el límite de conexión sshd
Los problemas de conexión como este son especialmente frecuentes cuando se intenta usar ssh para acceder a un enrutador u otro tipo de conmutador en caja discreto, ya que el número máximo predeterminado de conexiones es muy pequeño. Si bien no quiere permitirse sobrecargar el servidor, puede echar un vistazo a cuál es la configuración predeterminada.
Intente ejecutar 
en el servidor para encontrar cuántas conexiones puede manejar sshd. En la mayoría de los casos, el sistema debería tener por defecto 10 conexiones simultáneas, lo que debería ser suficiente para la mayoría de las estructuras de servidor en las que es probable que la mayoría de los usuarios necesiten usar ssh con regularidad.
