Mejores Prácticas de Seguridad SSH: Fortaleciendo tu Servidor y Cliente

Las mejores prácticas de seguridad SSH son importantes porque SSH suele ser la puerta de entrada a tus servidores. Una configuración SSH débil puede convertir una contraseña adivinada, una clave robada o un error de host confiable en acceso completo al shell.

No necesitas configuraciones exóticas para fortalecer SSH adecuadamente. Comienza con inicio de sesión basado en claves, usuarios restringidos, sin inicio de sesión directo como root, comportamiento cuidadoso del cliente y registros que te muestren cuando algo está mal.

Fortalecimiento de Seguridad del Lado del Servidor

La configuración de tu servidor SSH (sshd_config) establece las reglas sobre cómo los clientes se conectan y autentican.

1. Deshabilitar la Autenticación por Contraseña

La autenticación por contraseña es inherentemente vulnerable a ataques de fuerza bruta. Reemplazarla con autenticación basada en claves SSH es una de las mejoras de seguridad más efectivas que puedes hacer.

Por qué: Las claves SSH son mucho más complejas que las contraseñas y no pueden ser fácilmente adivinadas o descifradas mediante métodos de fuerza bruta. Proporcionan una forma mucho más fuerte de autenticación.
Cómo: Edita tu archivo sshd_config (típicamente ubicado en /etc/ssh/sshd_config) y establece PasswordAuthentication no. Después de hacer cambios, reinicia el servicio SSH:
```
sudo sshd -t
sudo systemctl reload sshd
```
Importante: Asegúrate de haber configurado y probado exitosamente la autenticación basada en claves SSH antes de deshabilitar la autenticación por contraseña para evitar quedarte fuera.

En algunas distribuciones el servicio se llama ssh, no sshd. Usa el nombre del servicio que proporcione tu sistema y mantén una sesión existente abierta mientras pruebas un nuevo inicio de sesión.

2. Trata los Cambios de Puerto como Reducción de Ruido

Cambiar el puerto SSH predeterminado de 22 puede reducir el ruido de escaneo automatizado. No es un sustituto de las claves, la aplicación de parches y el control de acceso.

Cómo: En sshd_config, cambia la directiva Port. Por ejemplo, para usar el puerto 2222:
```
Port 2222
```
Recuerda actualizar tus reglas de firewall para permitir tráfico en el nuevo puerto y especificar el puerto al conectarte desde tu cliente:
```
ssh -p 2222 usuario@tu_ip_del_servidor
```

3. Limitar el Acceso de Usuarios y Grupos

Controla qué usuarios y grupos pueden iniciar sesión a través de SSH.

AllowUsers y AllowGroups: Usa estas directivas en sshd_config para especificar explícitamente quién puede conectarse.
```
AllowUsers admin usuario1
AllowGroups sshusers
```
DenyUsers y DenyGroups: Alternativamente, úsalas para bloquear usuarios o grupos específicos.

4. Deshabilitar el Inicio de Sesión como Root

El inicio de sesión directo como root a través de SSH debe deshabilitarse para evitar que los atacantes apunten inmediatamente a la cuenta más poderosa. En su lugar, los usuarios deben iniciar sesión con sus propias cuentas y usar sudo para tareas administrativas.

Cómo: Establece PermitRootLogin no en sshd_config.

5. Configurar Tiempo de Inactividad y Keepalives

Evita que las sesiones SSH activas y desatendidas permanezcan abiertas indefinidamente.

ClientAliveInterval y ClientAliveCountMax: Estas configuraciones del lado del servidor envían paquetes nulos al cliente a intervalos regulares para verificar si la conexión sigue activa. Si el cliente no responde después de los intentos de ClientAliveCountMax, el servidor desconecta la sesión.
```
ClientAliveInterval 300  # Enviar un paquete cada 5 minutos
ClientAliveCountMax 2    # Desconectar después de 2 respuestas perdidas (10 minutos)
```

6. Fortalecer las Claves de Host

Asegúrate de que las claves de host de tu servidor estén protegidas y administradas adecuadamente.

Permisos: Verifica que los archivos de clave de host (por ejemplo, /etc/ssh/ssh_host_rsa_key) tengan permisos restrictivos (por ejemplo, 600) y sean propiedad de root.
Algoritmos: Prefiere claves de host modernas como Ed25519 cuando tus clientes las soporten. No elimines las claves de host existentes sin planificación, porque los clientes lo verán como un cambio de identidad del host.
Rotación: Rota las claves de host deliberadamente y anuncia las nuevas huellas digitales a través de un canal confiable.

Mejores Prácticas de Seguridad del Lado del Cliente

Asegurar tu máquina cliente y tus claves SSH es igual de crucial que el fortalecimiento del lado del servidor.

1. Proteger tus Claves Privadas

Tu clave privada SSH es la puerta de entrada a tus servidores. Trátala con el máximo cuidado.

Permisos: Asegúrate de que tu archivo de clave privada (por ejemplo, ~/.ssh/id_rsa) tenga permisos estrictos (por ejemplo, 600 o 400) para que solo tú puedas leerlo.
```
chmod 600 ~/.ssh/id_rsa
```
Frases de contraseña: Siempre usa una frase de contraseña fuerte para cifrar tu clave privada. Esto agrega una capa adicional de seguridad, requiriendo la frase de contraseña incluso si el archivo de clave se ve comprometido.
Evitar Copiar: No compartas tu clave privada con nadie ni la almacenes en ubicaciones inseguras.

2. Usar el Reenvío del Agente SSH con Cuidado

El reenvío del agente SSH te permite usar tus claves SSH locales para autenticarte en servidores remotos sin copiar tus claves privadas a esos servidores. Aunque es conveniente, puede ser un riesgo de seguridad si el servidor remoto se ve comprometido.

Habilitar: ssh -A usuario@tu_ip_del_servidor
Mejor Práctica: Deshabilita el reenvío del agente por defecto. Úsalo solo para hosts en los que confíes y prefiere alternativas como claves de implementación, bastión ProxyJump o credenciales de corta duración cuando se ajusten a tu flujo de trabajo.

3. Verificar las Huellas Digitales de las Claves de Host

Cuando te conectas a un servidor SSH por primera vez, tu cliente te solicita verificar la huella digital de la clave de host del servidor. Esto ayuda a prevenir ataques de intermediario.

Cómo: Siempre verifica la huella digital contra una fuente confiable, como tu consola en la nube, registros de aprovisionamiento o un administrador. Si la huella digital cambia inesperadamente, detente e investiga antes de aceptarla.

4. Mantener el Software del Cliente SSH Actualizado

Asegúrate de que tu software de cliente SSH (OpenSSH, PuTTY, etc.) se mantenga actualizado para beneficiarte de los últimos parches de seguridad y funciones.

Medidas de Seguridad Avanzadas

Más allá de los pasos fundamentales, considera estas técnicas avanzadas:

1. Autenticación Multifactor

Agrega MFA para el acceso SSH humano donde tu entorno lo soporte. Esto generalmente combina claves SSH con un código de un solo uso, aprobación push o autenticación respaldada por hardware.

Herramientas: Los módulos PAM, Duo, aplicaciones de autenticación y claves de seguridad de hardware pueden ser parte de un diseño de MFA para SSH.

2. Fail2ban

Fail2ban escanea los registros en busca de intentos repetidos de autenticación fallidos y puede agregar bloqueos temporales de firewall para la IP de origen. Las rutas de registro varían según la distribución; Debian y Ubuntu comúnmente usan /var/log/auth.log, mientras que muchos sistemas de la familia RHEL registran a través de journald o /var/log/secure.

Instalación: Generalmente disponible a través de los administradores de paquetes (sudo apt install fail2ban o sudo yum install fail2ban).
Configuración: Configura las cárceles en /etc/fail2ban/jail.local para monitorear los registros SSH y definir tiempos de bloqueo y umbrales.

3. Configuración del Firewall

Emplea un firewall (como ufw, firewalld o iptables) para restringir el acceso a tu puerto SSH (ya sea predeterminado o personalizado) solo desde direcciones o rangos IP confiables.

Ejemplo (ufw):

sudo ufw allow from ip_confiable to any port 22
sudo ufw enable

Conclusión

Asegurar SSH es un hábito continuo. Usa autenticación basada en claves, deshabilita el inicio de sesión directo como root, restringe quién puede conectarse, protege tus claves privadas y verifica las huellas digitales del host. Luego agrega límites de firewall, MFA y protección contra fuerza bruta donde el riesgo justifique la configuración adicional.