Mejores Prácticas para Fortalecer la Seguridad SSH en Servidores Linux

Asegura tu servidor Linux de inmediato dominando estas técnicas esenciales de fortalecimiento de SSH. Esta guía experta proporciona pasos prácticos, centrándose en los cambios de configuración en `sshd_config`. Aprende a deshabilitar el inicio de sesión root de alto riesgo, implementar autenticación obligatoria basada en claves para eliminar contraseñas débiles, cambiar el puerto predeterminado e instalar Fail2Ban para limitar eficazmente la velocidad contra ataques de fuerza bruta. Protege tu sistema transformando SSH en un canal robusto y seguro.

Mejores Prácticas para Reforzar la Seguridad SSH en Servidores Linux

SSH suele ser la primera puerta que se abre en un servidor Linux, por lo que reforzar la seguridad SSH debe ocurrir antes de exponer ese host a internet. Los bots intentan constantemente contraseñas débiles, credenciales reutilizadas y cuentas predeterminadas en el puerto 22.

El objetivo es simple: mantener el acceso remoto utilizable para usted y doloroso para los atacantes. Comience desde una segunda sesión de terminal, mantenga su sesión SSH actual abierta y pruebe cada cambio antes de reiniciar el demonio.

Haga una Copia de Seguridad y Pruebe la Configuración Primero

Antes de editar /etc/ssh/sshd_config, haga una copia de seguridad. Un error tipográfico puede bloquearle el acceso al servidor.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_$(date +%F)

Después de editar, verifique la sintaxis:

sudo sshd -t

Si la prueba pasa, recargue o reinicie SSH. El nombre del servicio es comúnmente sshd en sistemas estilo RHEL y ssh en Debian/Ubuntu:

sudo systemctl restart sshd
# o
sudo systemctl restart ssh

1. Deshabilitar el Inicio de Sesión Root

El inicio de sesión directo como root le da al atacante el nombre de usuario más valioso de inmediato. Use una cuenta de usuario normal, luego eleve privilegios con sudo cuando necesite acceso administrativo.

Paso de Configuración

Abra /etc/ssh/sshd_config y localice la directiva PermitRootLogin. Cambie su valor a no.

# Antes:
# PermitRootLogin yes

# Después (Mejor Práctica):
PermitRootLogin no

Antes de reiniciar SSH, confirme que puede iniciar sesión como un usuario estándar con privilegios sudo.

2. Exigir Autenticación Basada en Claves

La autenticación por contraseña es fácil de atacar a gran escala. Las claves SSH son más difíciles de adivinar, más fáciles de rotar y más seguras para la administración diaria cuando protege la clave privada con una frase de contraseña.

Generar e Instalar Claves

  1. Genere el par de claves en su máquina local:
    ssh-keygen -t ed25519 -C "[email protected]"
    
  2. Copie la clave pública al servidor:
    ssh-copy-id -i ~/.ssh/id_ed25519 usuario@su_ip_del_servidor
    

Deshabilitar la Autenticación por Contraseña

Una vez que confirme que puede iniciar sesión correctamente usando su clave SSH, deshabilite la autenticación por contraseña por completo.

# Deshabilitar contraseñas
PasswordAuthentication no

# Asegurar que las claves estén habilitadas
PubkeyAuthentication yes

Ed25519 es un buen valor predeterminado para claves nuevas. Si necesita RSA para compatibilidad con sistemas antiguos, use una clave grande, por ejemplo de 4096 bits.

3. Considere Cambiar el Puerto SSH Predeterminado

Cambiar SSH del puerto TCP 22 a un puerto no estándar puede reducir los escaneos automatizados ruidosos. No es un reemplazo para claves, controles de acceso o limitación de tasa, porque cualquiera aún puede descubrir el puerto abierto con un escaneo.

Paso de Configuración

En /etc/ssh/sshd_config, cambie la directiva Port:

# Antes:
# Port 22

# Después (Ejemplo de puerto no estándar):
Port 22222

Actualice su cortafuegos y cualquier grupo de seguridad en la nube antes de reiniciar SSH. De lo contrario, su nuevo demonio SSH podría estar escuchando en un puerto al que no pueda acceder.

Ejemplo usando firewalld (CentOS/RHEL):

sudo firewall-cmd --permanent --add-port=22222/tcp
sudo firewall-cmd --reload

4. Limitar el Acceso a Usuarios y Grupos Específicos

Si solo un pequeño conjunto de personas debe usar SSH, indíquelo en sshd_config. Esto bloquea que cuentas locales olvidadas se conviertan en puntos de entrada remotos.

Directivas de Configuración

Use una o ambas de las siguientes directivas en sshd_config:

  1. Permitir usuarios específicos:
    AllowUsers alicia bob
    
  2. Permitir grupos específicos:
    AllowGroups sshaccess admins
    

Si estas directivas están presentes, cualquier usuario o grupo no listado explícitamente será denegado.

5. Mantener Valores Predeterminados SSH Modernos y Deshabilitar Métodos Heredados

Las versiones actuales de OpenSSH ya usan el protocolo SSH 2; la compatibilidad con el protocolo 1 anterior se ha eliminado de OpenSSH moderno. Evite copiar fragmentos de endurecimiento antiguos que incluyan directivas Protocol no compatibles o una lista de cifrados obsoleta. Estos pueden romper SSH después de una actualización.

Concéntrese en deshabilitar mecanismos de confianza heredados a menos que sepa que los necesita:

HostbasedAuthentication no
IgnoreRhosts yes
PermitEmptyPasswords no

Si su organización requiere una política personalizada de cifrados, MAC o intercambio de claves, verifique qué admite su servidor instalado antes de cambiarlo:

sshd -T | grep -E '^(ciphers|macs|kexalgorithms) '

Luego aplique solo una política probada que coincida con su base de clientes. Una lista demasiado estricta puede bloquear hosts de automatización antiguos.

6. Agregar Limitación de Tasa con Fail2Ban

Incluso con autenticación basada en claves, las sondas repetidas desperdician recursos y saturan los registros. Fail2Ban monitorea los registros de autenticación y agrega prohibiciones temporales del cortafuegos después de fallos repetidos.

  1. Instale Fail2Ban:

    # Debian/Ubuntu
    sudo apt update && sudo apt install fail2ban
    
    # RHEL/CentOS/Fedora
    sudo dnf install fail2ban
    
  2. Habilite la jaula sshd. Muchos sistemas incluyen una configuración predeterminada, pero debe colocar las anulaciones locales en /etc/fail2ban/jail.local o en un archivo dentro de /etc/fail2ban/jail.d/.

    [sshd]
    enabled = true
    port = 22222
    maxretry = 5
    bantime = 1h
    
  3. Inicie el servicio:

    sudo systemctl enable --now fail2ban
    

Si cambió el puerto SSH, haga que la jaula de Fail2Ban coincida con el nuevo puerto.

7. Ajustar la Configuración de Sesión y Autenticación

Estas configuraciones ayudan a cerrar sesiones inactivas y eliminar rutas de autenticación débiles:

Directiva Valor Recomendado Propósito
ClientAliveInterval 300 Envía una verificación de actividad del lado del servidor cada 300 segundos.
ClientAliveCountMax 3 Desconecta después de tres verificaciones sin respuesta.
UsePAM yes Habilita Módulos de Autenticación Conectables (PAM) para políticas de seguridad adicionales del sistema local.
PermitEmptyPasswords no Bloquea cuentas con contraseñas vacías para que no inicien sesión.
MaxAuthTries 3 Limita los intentos de autenticación repetidos por conexión.
X11Forwarding no Deshabilita el reenvío X11 a menos que realmente lo use.

Lista de Verificación de Endurecimiento

Use esta lista de verificación para asegurarse de que su servidor cumpla con los estándares básicos de endurecimiento SSH:

  1. Haga una copia de seguridad de sshd_config antes de realizar cambios.
  2. Establezca PermitRootLogin no.
  3. Establezca PasswordAuthentication no (después de configurar las claves).
  4. Cambie el Port a un valor no estándar.
  5. Actualice el cortafuegos para permitir el nuevo puerto.
  6. Use AllowUsers o AllowGroups para restringir el acceso.
  7. Deshabilite métodos de confianza heredados como HostbasedAuthentication.
  8. Instale y configure Fail2Ban.
  9. Verifique la configuración con sshd -t antes de reiniciar.

Reforzar la seguridad SSH funciona mejor como defensa en capas. Las claves detienen la adivinación de contraseñas, las restricciones de usuario reducen quién puede conectarse, las reglas del cortafuegos limitan de dónde provienen las conexiones y Fail2Ban ralentiza las sondas repetidas. Mantenga una sesión de trabajo abierta mientras prueba, luego documente el nuevo puerto y método de inicio de sesión para cualquiera que opere el servidor.