Posible sesión de SSH secuestrada y mejores prácticas de SSH

Estoy enloqueciendo un poco en este momento. Estoy SSHing en un servidor remoto que he comisionado recientemente. Estoy haciendo esto como root. He instalado fail2ban y tenía una gran cantidad de direcciones IP prohibidas en el registro.

La última vez que inicié sesión, noté que mi terminal estaba muy floja y luego mi conexión a Internet se cortó. Cuando lo volví a comprar después de unos 5 minutos, volví a iniciar sesión en el servidor e hice un 'quién' y me di cuenta de que había dos usuarios root conectados. Pensé que si mi conexión terminara el proceso de la última sesión habría sido detenido en el servidor?

La conexión terminó con un 'Error de escritura: tubería rota' cuando me desconecté por primera vez. Maté la sesión de bash con la otra raíz. No sé mucho acerca de la seguridad ssh, sin embargo, ¿podrían ser secuestradas las sesiones? ¿hay alguna manera de verificar esto? Necesito continuar iniciando sesión a través de ssh ¿qué precauciones debo tomar? Si de alguna manera pasara por un proxy para llegar a mi servidor (como un hombre en medio del ataque), ¿podrían secuestrar mi sesión ssh?

Los inicios de sesión de la raíz probablemente cuelgan sesiones de shell que alguna vez fuiste tú. Es probable que su servidor también reciba dDOS con todos los intentos de inicio de sesión que lo obstaculizan.

Bloquee SSH. No permita el inicio de sesión de root, y las solicitudes que intentan forzar la fuerza bruta de esta máquina fallarán de inmediato (con muchos menos recursos). Inicie sesión como usuario normal y aumente los permisos a través de sudo, una práctica que debería estar haciendo de todos modos. También restrinja el inicio de sesión SSH a una lista de IP de clientes para que las máquinas desagradables ni siquiera puedan intentar iniciar sesión.

Use claves SSH en lugar de contraseñas para el inicio de sesión del usuario. Son más fáciles de manejar y se pueden proteger con contraseña en caso de que accidentalmente entregue una clave privada en el lugar equivocado (lo que le da tiempo para reemplazarla e invalidar la anterior). Como @EEAA mencionó en los comentarios, también debe deshabilitar la autenticación basada en contraseña si desea restringir a los clientes a usar solo claves en lugar de contraseñas y claves.

Si los clanes mongol continúan golpeando la muralla de su ciudad, tal vez mueva SSH a un puerto alto diferente (menos de 1024, como señaló @AustinBurke, para usar un puerto privilegiado) en lugar de 22. Esto reducirá el tráfico en ese puerto si esto es un problema para ti (y la mayoría de los bots no son muy elegantes, por lo que solo intentarán el 22). No impedirá que las cosas prueben el puerto 22 o incluso escanee su máquina para ver qué puerto está escuchando en SSH, y en la mayoría de los casos es un inconveniente innecesario. Pero puede ayudar.

Otros podrían proporcionar más consejos, pero estas son medidas de seguridad bastante genéricas para un servidor SSH de cara al público.