Publicado originalmente en Ask Ubuntu
Si ha descartado cualquier factor "externo", el siguiente conjunto de pasos generalmente ayuda a reducirlo. Entonces, aunque esto no responde directamente a su pregunta, puede ayudar a rastrear la causa del error.
Resolución de problemas sshd
Lo que generalmente encuentro muy útil en tales casos es comenzar sshd sin dejar que se demonice. El problema en mi caso fue que ni syslog ni auth.log mostró algo significativo.
Cuando lo inicié desde la terminal obtuve:
# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.
¡Mucho mejor! Este mensaje de error me permitió ver qué está mal y solucionarlo. Ninguno de los archivos de registro contenía esta salida.
Nota: al menos en Ubuntu el $(which sshd) es el mejor método para satisfacer sshd requisito de un camino absoluto. De lo contrario obtendrá el siguiente error:sshd re-exec requires execution with an absolute path . El -p 10222 hace sshd escuche en ese puerto alternativo, anulando el archivo de configuración; esto es para que no entre en conflicto con la ejecución potencial de sshd instancias. Asegúrese de elegir un puerto libre aquí.
Finalmente:conéctese al puerto alternativo (ssh -p 10222 [email protected] ).
Este método me ha ayudado muchas veces a encontrar problemas, ya sean problemas de autenticación u otros tipos. Para obtener una salida realmente detallada a stdout , usa $(which sshd) -Ddddp 10222 (tenga en cuenta el dd agregado para aumentar la verbosidad). Para obtener más bondad de depuración, consulte man sshd .
La principal ventaja de este método es que te permite comprobar el sshd configuración sin tener que reiniciar el sshd en el puerto predeterminado. Normalmente esto no debería interferir con las conexiones SSH existentes, pero lo he visto. Entonces, esto le permite a uno validar el archivo de configuración antes de, potencialmente, cortar el acceso a un servidor remoto (por ejemplo, tengo eso para algunos VPS e incluso para servidores físicos donde necesito pagar extra para obtener acceso fuera de banda a la máquina).
También puede tener un host cuya memoria esté tan fragmentada que no pueda asignar a una página una memoria contigua para bifurcar el proceso de alojamiento de una sesión SSH.
En tal caso, puede recibir cualquiera de los mensajes:
ssh_exchange_identification: read: Connection reset by peer
o:
Connection closed by aaa.bbb.ccc.ddd
dependiendo de qué tan lejos llegue el anfitrión antes de rescatar.
Si la fragmentación de la memoria es la causa aparente, la solución es acceder al servidor por otros medios y reiniciar algunos de los servicios pertinentes. Descubrí que Apache y MySQL son los culpables de las máquinas virtuales, ya que las máquinas virtuales no tienen una partición de intercambio. De lo contrario, reinicie el host.
Por si acaso, porque esto me pasó a mí. ¡Asegúrese de tener sshd ejecutándose en el host!
Es una falla estúpida, pero podría ser realmente tu problema.