Seguridad SSH 17 min de lectura

Guía de Hardening SSH en 2026: Criptografía Post-Cuántica, Certificados y Mejores Prácticas

Guía práctica para endurecer SSH en servidores Linux en 2026. Cubre criptografía post-cuántica con OpenSSH 10.0, certificados con CA propia, Fail2Ban, 2FA, bastiones SSH e integración con HashiCorp Vault.

Editorial Team

Introducción: Por qué la seguridad SSH es más crítica que nunca

SSH (Secure Shell) es, sin exagerar, el protocolo más importante para cualquier administrador de sistemas Linux. Lo usamos todos los días — para gestionar servidores, desplegar aplicaciones, transferir archivos sensibles. Es tan ubicuo que a veces olvidamos lo crítico que es mantenerlo seguro. Y ahí es donde empiezan los problemas.

En 2026, el panorama de amenazas ha cambiado bastante. Los ataques de fuerza bruta contra SSH son más sofisticados que nunca, los ataques de tipo «almacenar ahora, descifrar después» ya no son ciencia ficción, y las vulnerabilidades en implementaciones antiguas siguen siendo explotadas activamente. La buena noticia es que OpenSSH 10.0 ha dado un paso histórico al establecer el intercambio de claves post-cuántico como predeterminado. Eso es enorme.

Así que, vamos a ello. Esta guía cubre todo lo que necesitas saber sobre hardening SSH: desde lo básico hasta técnicas avanzadas como autenticación con certificados, criptografía post-cuántica e integración con herramientas de detección de intrusiones. Da igual si administras un solo servidor o una infraestructura empresarial con cientos de nodos — aquí vas a encontrar lo que necesitas para blindar tus conexiones.

Fundamentos del hardening SSH: la configuración base

Deshabilitar el acceso root directo

Esto es lo primero que deberías hacer. Siempre. Permitir que root inicie sesión directamente por SSH es probablemente uno de los errores más comunes (y más peligrosos) que veo en servidores en producción. Si un atacante compromete las credenciales de root, tiene acceso total al sistema. Así de simple.

# Editar /etc/ssh/sshd_config
PermitRootLogin no

# Alternativa: permitir solo con claves (sin contraseña)
PermitRootLogin prohibit-password

Lo que debes hacer en su lugar es que cada administrador use una cuenta personal con privilegios limitados y escale con sudo cuando sea necesario. Además de ser más seguro, te da trazabilidad completa de quién hizo qué.

Eliminar la autenticación por contraseña

Honestamente, en 2026 seguir dependiendo de contraseñas para autenticarse por SSH es como proteger una cámara acorazada con un candado de bicicleta. Las contraseñas son vulnerables a ataques de fuerza bruta, diccionario y phishing. La autenticación basada en claves criptográficas es infinitamente más segura.

# Deshabilitar autenticación por contraseña
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

# Habilitar solo autenticación por clave pública
PubkeyAuthentication yes

Un consejo importante: antes de deshabilitar la autenticación por contraseña, asegúrate de haber configurado al menos una clave SSH autorizada para tu cuenta. De lo contrario, te vas a quedar fuera del servidor. Me ha pasado. No es divertido.

Generar claves SSH modernas con Ed25519

Ed25519 ofrece una seguridad equivalente a RSA de 3072 bits pero con claves mucho más cortas y operaciones más rápidas. Es el estándar recomendado para claves SSH nuevas.

# Generar una clave Ed25519 con comentario descriptivo
ssh-keygen -t ed25519 -C "admin@servidor-produccion" -f ~/.ssh/id_ed25519

# Si necesitas compatibilidad con sistemas antiguos, usa RSA con mínimo 4096 bits
ssh-keygen -t rsa -b 4096 -C "admin@servidor-legacy" -f ~/.ssh/id_rsa_4096

Un dato relevante: a partir de OpenSSH 10.0, el soporte para DSA ha sido completamente eliminado, y las claves RSA menores de 3072 bits generan advertencias. Si todavía tienes claves antiguas por ahí, es momento de migrar.

Restringir usuarios y grupos con acceso SSH

Limitar qué usuarios pueden conectarse por SSH reduce drásticamente la superficie de ataque. Es una de esas medidas que toma cinco minutos y puede ahorrarte muchos dolores de cabeza.

# Permitir solo usuarios específicos
AllowUsers admin deployer auditor

# O permitir por grupo (más escalable)
AllowGroups ssh-users ssh-admins

# Denegar usuarios específicos (útil como capa adicional)
DenyUsers guest test temp

Configuración avanzada de cifrado y algoritmos

Selección de algoritmos criptográficos robustos

Aquí es donde las cosas se ponen interesantes. La elección de cifrados, algoritmos de intercambio de claves y MACs (Message Authentication Codes) es crucial para la seguridad real de tus conexiones SSH. Usar algoritmos débiles u obsoletos es como dejar la puerta trasera abierta. La siguiente configuración refleja las mejores prácticas para 2026, incluyendo el soporte post-cuántico.

# /etc/ssh/sshd_config - Configuración de cifrado endurecida

# Algoritmos de intercambio de claves (incluye post-cuántico)
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,[email protected]

# Cifrados simétricos (solo AEAD)
Ciphers [email protected],[email protected],[email protected]

# MACs (solo variantes encrypt-then-MAC)
MACs [email protected],[email protected]

# Claves de host (priorizar Ed25519)
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Tamaño mínimo de clave RSA
RequiredRSASize 3072

El algoritmo mlkem768x25519-sha256, que viene como predeterminado en OpenSSH 10.0, combina ML-KEM (un mecanismo de encapsulación de claves estandarizado por NIST) con la curva elíptica X25519. Es un enfoque híbrido que te da resistencia cuántica sin sacrificar la seguridad clásica que ya conocemos y en la que confiamos.

Entendiendo la criptografía post-cuántica en SSH

Vamos a ser claros: la amenaza de la computación cuántica para la criptografía actual no es algo teórico ni lejano. Los ataques «almacenar ahora, descifrar después» son reales — adversarios con capacidad de interceptar tráfico SSH cifrado hoy podrían descifrarlo cuando dispongan de computadores cuánticos suficientemente potentes. Si manejas información clasificada o de larga vigencia, la migración a algoritmos post-cuánticos debería ser una prioridad.

OpenSSH ha ofrecido intercambio de claves post-cuántico desde la versión 9.0 (abril 2022) con sntrup761x25519-sha512, y la versión 10.1 advertirá cuando se seleccione un esquema no post-cuántico. La transición es inevitable. Mejor planificarla ahora que lidiar con problemas de compatibilidad después.

Autenticación basada en certificados SSH

¿Por qué certificados en lugar de claves?

La autenticación con claves públicas es mucho mejor que las contraseñas, eso está claro. Pero tiene un problema serio de escalabilidad. En una infraestructura con cientos de servidores, gestionar archivos authorized_keys individuales se convierte en una auténtica pesadilla. Cada vez que alguien se une al equipo, cambia de rol o se va de la empresa, toca actualizar potencialmente cientos de archivos en cientos de servidores.

Los certificados SSH resuelven esto de forma elegante mediante una Autoridad Certificadora (CA) centralizada. En lugar de distribuir claves públicas a cada servidor, la CA firma las claves de los usuarios generando certificados de corta duración. Los servidores solo necesitan confiar en la clave pública de la CA. Mucho más limpio.

Configurar una Autoridad Certificadora SSH

Lo que más sorprende a la gente es lo sencillo que es montar una CA SSH. Básicamente necesitas generar dos pares de claves: uno para firmar certificados de usuario y otro para certificados de host.

# Crear directorio seguro para las claves de la CA
mkdir -p /etc/ssh/ca
chmod 700 /etc/ssh/ca

# Generar la clave de la CA para firmar certificados de usuario
ssh-keygen -t ed25519 -f /etc/ssh/ca/ca_user_key -C "CA-Usuarios-Produccion"

# Generar la clave de la CA para firmar certificados de host
ssh-keygen -t ed25519 -f /etc/ssh/ca/ca_host_key -C "CA-Hosts-Produccion"

# Proteger las claves privadas de la CA
chmod 600 /etc/ssh/ca/ca_user_key /etc/ssh/ca/ca_host_key

Importante: Las claves privadas de la CA son el activo más valioso de todo el sistema. Protégelas con una frase de paso fuerte y, si es posible, almacénalas en un HSM o en un token FIDO2. Si un atacante obtiene la clave privada de la CA, podrá generar certificados válidos para cualquier usuario o host. Ese es un escenario que no quieres ni imaginar.

Firmar certificados de usuario

Para firmar la clave pública de un usuario y generar un certificado:

# Firmar la clave pública de un usuario con validez de 8 horas
ssh-keygen -s /etc/ssh/ca/ca_user_key \
  -I "carlos-devops-team" \
  -n carlos,deployer \
  -V +8h \
  -z 1001 \
  /home/carlos/.ssh/id_ed25519.pub

# Verificar el certificado generado
ssh-keygen -L -f /home/carlos/.ssh/id_ed25519-cert.pub

Los parámetros clave son:

  • -s: Especifica la clave privada de la CA para firmar.
  • -I: Identificador del certificado (aparece en los logs, así que ponle algo descriptivo).
  • -n: Nombres de usuario (principals) autorizados.
  • -V: Período de validez. Certificados de corta duración (+8h, +12h) son lo ideal.
  • -z: Número de serie único para el certificado.

Firmar certificados de host

¿Conoces esa pregunta molesta de verificación de fingerprint que aparece la primera vez que te conectas a un servidor? Los certificados de host la eliminan. Cuando el servidor presenta un certificado firmado por una CA de confianza, el cliente lo acepta automáticamente. Una cosa menos de la que preocuparse.

# Firmar la clave de host del servidor
ssh-keygen -s /etc/ssh/ca/ca_host_key \
  -I "servidor-web-prod-01" \
  -h \
  -n servidor-web-prod-01.ejemplo.com,10.0.1.50 \
  -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

# Configurar el servidor para usar el certificado de host
# Añadir en /etc/ssh/sshd_config:
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Configurar servidores para confiar en la CA

Para que los servidores acepten certificados de usuario firmados por tu CA, añade lo siguiente a la configuración:

# En /etc/ssh/sshd_config del servidor
TrustedUserCAKeys /etc/ssh/ca/ca_user_key.pub

# Opcional: restringir principals permitidos por archivo
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# Crear archivo de principals para cada usuario
echo -e "carlos\ndeployer" > /etc/ssh/auth_principals/carlos
echo -e "admin\nauditor" > /etc/ssh/auth_principals/admin

Para que los clientes confíen en los certificados de host firmados por la CA, añade esto en ~/.ssh/known_hosts o /etc/ssh/ssh_known_hosts:

# Confiar en la CA para todos los hosts del dominio
@cert-authority *.ejemplo.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... CA-Hosts-Produccion

Protección contra ataques de fuerza bruta

Configuración de límites de conexión en sshd

OpenSSH trae varias directivas para limitar los intentos de autenticación y las conexiones simultáneas. Son fáciles de configurar y hacen una diferencia enorme.

# Limitar intentos de autenticación por conexión
MaxAuthTries 3

# Limitar conexiones no autenticadas simultáneas
MaxStartups 10:30:60

# Tiempo máximo para completar la autenticación (en segundos)
LoginGraceTime 30

# Desconectar sesiones inactivas
ClientAliveInterval 300
ClientAliveCountMax 2

La directiva MaxStartups 10:30:60 es bastante ingeniosa: comienza a rechazar conexiones con una probabilidad del 30% cuando hay 10 conexiones no autenticadas pendientes, y esa probabilidad sube linealmente hasta el 100% al llegar a 60 conexiones.

Implementar Fail2Ban para SSH

Fail2Ban es una de esas herramientas que todo servidor debería tener. Monitoriza los logs del sistema y bloquea automáticamente las IPs que muestran comportamiento sospechoso. Es una capa de defensa casi imprescindible contra ataques de fuerza bruta.

# Instalar Fail2Ban
# Debian/Ubuntu
sudo apt install fail2ban

# RHEL/CentOS/Fedora
sudo dnf install fail2ban

Crea un archivo de configuración local para SSH (así no se sobrescribe durante las actualizaciones):

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
backend = systemd
filter = sshd
maxretry = 3
findtime = 600
bantime = 3600
banaction = iptables-multiport

# Configuración agresiva para reincidentes
[sshd-aggressive]
enabled = true
port = ssh
backend = systemd
filter = sshd[mode=aggressive]
maxretry = 2
findtime = 86400
bantime = 604800
# Activar y verificar Fail2Ban
sudo systemctl enable --now fail2ban

# Verificar estado del jail SSH
sudo fail2ban-client status sshd

# Ver IPs bloqueadas actualmente
sudo fail2ban-client get sshd banned

Protección con listas de acceso y firewall

Si el acceso SSH solo es necesario desde redes o IPs conocidas (que es lo habitual en entornos corporativos), configura reglas de firewall para restringir el acceso.

# Con nftables (recomendado sobre iptables en 2026)
sudo nft add rule inet filter input ip saddr { 10.0.0.0/8, 192.168.1.0/24 } tcp dport 22 accept
sudo nft add rule inet filter input tcp dport 22 drop

# Con firewalld (RHEL/CentOS/Fedora)
sudo firewall-cmd --permanent --zone=trusted --add-source=10.0.0.0/8
sudo firewall-cmd --permanent --zone=trusted --add-service=ssh
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reload

Configuraciones avanzadas de seguridad

Cambiar el puerto predeterminado de SSH

Vale, seamos honestos: cambiar el puerto SSH no es una medida de seguridad real. Es seguridad por oscuridad. Pero lo que sí hace, y bastante bien, es reducir el ruido de ataques automatizados y bots que escanean el puerto 22. Menos ruido en los logs significa que puedes detectar los ataques reales más fácilmente.

# En /etc/ssh/sshd_config
Port 2222

# Si usas SELinux, permitir el nuevo puerto
sudo semanage port -a -t ssh_port_t -p tcp 2222

# Si usas firewalld, abrir el nuevo puerto
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Implementar autenticación de dos factores (2FA)

Combinar claves SSH con un segundo factor de autenticación es una de las mejores cosas que puedes hacer por la seguridad de tus servidores. Google Authenticator PAM es una solución probada que funciona muy bien.

# Instalar el módulo PAM de Google Authenticator
sudo apt install libpam-google-authenticator  # Debian/Ubuntu
sudo dnf install google-authenticator         # RHEL/Fedora

# Configurar Google Authenticator para el usuario
google-authenticator -t -d -f -r 3 -R 30 -w 3

Ahora configura PAM para requerir el código TOTP además de la clave SSH:

# /etc/pam.d/sshd - Añadir al final
auth required pam_google_authenticator.so nullok

# /etc/ssh/sshd_config - Habilitar autenticación multifactor
AuthenticationMethods publickey,keyboard-interactive
ChallengeResponseAuthentication yes
UsePAM yes

# Reiniciar sshd
sudo systemctl restart sshd

Con esta configuración, los usuarios primero presentan su clave SSH y luego proporcionan un código TOTP. El parámetro nullok permite que usuarios que aún no han configurado 2FA puedan acceder temporalmente — quítalo una vez que todos estén configurados.

Configurar un bastión SSH (Jump Host)

Un bastión SSH es un servidor endurecido que actúa como punto de entrada único a tu red interna. Todos los accesos SSH a servidores internos pasan a través del bastión, lo que centraliza la auditoría y reduce la superficie de ataque de forma considerable. En mi experiencia, esta es una de las mejores inversiones en seguridad que puedes hacer en una infraestructura mediana o grande.

# ~/.ssh/config - Configuración del cliente para usar bastión
Host bastion
    HostName bastion.ejemplo.com
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

Host servidor-interno-*
    ProxyJump bastion
    User deployer
    IdentityFile ~/.ssh/id_ed25519_deploy

# Ejemplo de uso: conexión transparente a través del bastión
# ssh servidor-interno-web01
# Configuración del bastión (/etc/ssh/sshd_config)
# Deshabilitar port forwarding y tunneling
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Permitir solo ProxyJump (forwarding de stdin/stdout)
AllowStreamLocalForwarding no

# Registrar toda la actividad
LogLevel VERBOSE

Auditoría y monitorización de sesiones SSH

Configurar logging detallado

Tener un registro detallado de las conexiones SSH no es opcional — es esencial tanto para detectar intrusiones como para cumplir con regulaciones. OpenSSH permite configurar diferentes niveles de verbosidad en sus logs.

# /etc/ssh/sshd_config
LogLevel VERBOSE

# Para depuración (no usar en producción permanentemente)
# LogLevel DEBUG3

Con LogLevel VERBOSE, sshd registra el fingerprint de la clave utilizada en cada autenticación, lo que te permite rastrear exactamente qué clave se usó para cada acceso. Muy útil cuando tienes múltiples claves autorizadas.

# Consultar logs SSH con journalctl
sudo journalctl -u sshd --since "1 hour ago" --no-pager

# Buscar intentos fallidos de autenticación
sudo journalctl -u sshd | grep -i "failed\|invalid\|refused"

# Monitorizar conexiones SSH en tiempo real
sudo journalctl -u sshd -f

Auditoría con auditd

El subsistema de auditoría del kernel Linux (auditd) proporciona un registro a nivel de sistema operativo que es mucho más difícil de evadir que los logs de aplicación. Si un atacante compromete el servicio SSH, los logs de auditd siguen siendo confiables (asumiendo que no tiene acceso root).

# Reglas de auditoría para SSH (/etc/audit/rules.d/ssh.rules)

# Monitorizar cambios en la configuración de sshd
-w /etc/ssh/sshd_config -p wa -k sshd_config_change

# Monitorizar cambios en claves autorizadas
-w /root/.ssh/authorized_keys -p wa -k root_ssh_keys
-w /home/ -p wa -k user_ssh_keys

# Monitorizar ejecución de ssh-keygen
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/ssh-keygen -k ssh_keygen_exec

# Monitorizar conexiones al puerto SSH
-a always,exit -F arch=b64 -S connect -F a2=16 -F success=1 -k ssh_connection

# Recargar reglas de auditoría
sudo augenrules --load

Registro de sesiones para cumplimiento normativo

Para entornos que requieren cumplimiento normativo (PCI DSS, HIPAA, SOC2), puede que necesites registrar las sesiones SSH completas. No es algo que recomiende en todos los entornos por cuestiones de privacidad, pero cuando la regulación lo exige, no hay alternativa.

# Opción 1: Usar ForceCommand con script
# /etc/ssh/sshd_config
ForceCommand /usr/local/bin/ssh-session-logger.sh

# /usr/local/bin/ssh-session-logger.sh
#!/bin/bash
LOG_DIR="/var/log/ssh-sessions"
LOG_FILE="${LOG_DIR}/${USER}_$(date +%Y%m%d_%H%M%S)_$$"
mkdir -p "$LOG_DIR"
echo "Sesión SSH iniciada: $(date) por ${USER} desde ${SSH_CLIENT}" >> "${LOG_FILE}.info"
exec script -q -f "${LOG_FILE}.log" -c "${SHELL:-/bin/bash}"

Hardening SSH para contenedores y Kubernetes

SSH en entornos containerizados

En entornos de contenedores modernos, la relación con SSH cambia por completo. La mejor práctica es directamente evitar SSH dentro de los contenedores y usar herramientas nativas como kubectl exec o docker exec. Dicho esto, hay escenarios donde SSH en los nodos host sigue siendo necesario, y ahí es donde entra esta configuración.

# Configuración SSH endurecida para nodos de Kubernetes
# /etc/ssh/sshd_config en nodos worker/control plane

# Solo acceso desde la red de gestión
ListenAddress 10.0.100.0

# Restringir a usuarios de operaciones
AllowGroups k8s-admins node-operators

# Deshabilitar todo tipo de forwarding
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
X11Forwarding no

# Tiempo de sesión limitado
ClientAliveInterval 180
ClientAliveCountMax 1

# Logging para auditoría
LogLevel VERBOSE

Gestión de claves SSH con HashiCorp Vault

Cuando la infraestructura crece, gestionar certificados SSH manualmente se vuelve insostenible. HashiCorp Vault puede actuar como CA SSH automatizada, generando certificados firmados bajo demanda con políticas de acceso granulares. Es una solución potente que, una vez configurada, simplifica enormemente la gestión.

# Habilitar el motor de secretos SSH en Vault
vault secrets enable -path=ssh-client-signer ssh

# Configurar la CA
vault write ssh-client-signer/config/ca generate_signing_key=true

# Crear un rol para desarrolladores
vault write ssh-client-signer/roles/dev-role -<<EOF
{
  "algorithm_signer": "rsa-sha2-256",
  "allow_user_certificates": true,
  "allowed_users": "deployer,developer",
  "allowed_extensions": "permit-pty",
  "default_extensions": {"permit-pty": ""},
  "key_type": "ca",
  "default_user": "deployer",
  "ttl": "8h",
  "max_ttl": "24h"
}
EOF

# Firmar una clave de usuario con Vault
vault write ssh-client-signer/sign/dev-role \
  public_key=@$HOME/.ssh/id_ed25519.pub

Script de auditoría automatizada de configuración SSH

Para verificar que la configuración SSH de tu servidor cumple con las mejores prácticas, puedes usar este script de auditoría. Lo he adaptado para que sea fácil de extender con tus propias comprobaciones:

#!/bin/bash
# ssh-audit-config.sh - Auditoría de configuración SSH
# Uso: sudo bash ssh-audit-config.sh

SSHD_CONFIG="/etc/ssh/sshd_config"
ISSUES=0
WARNINGS=0

echo "============================================"
echo "  Auditoría de Seguridad SSH - $(date)"
echo "  Servidor: $(hostname)"
echo "============================================"
echo ""

check_config() {
    local param="$1"
    local expected="$2"
    local severity="$3"
    local actual
    actual=$(sshd -T 2>/dev/null | grep -i "^${param} " | awk '{print $2}')

    if [ -z "$actual" ]; then
        echo "[?] ${param}: no encontrado"
        return
    fi

    if [ "${actual,,}" = "${expected,,}" ]; then
        echo "[OK] ${param} = ${actual}"
    else
        if [ "$severity" = "CRITICO" ]; then
            echo "[FALLO] ${param} = ${actual} (esperado: ${expected}) [${severity}]"
            ((ISSUES++))
        else
            echo "[AVISO] ${param} = ${actual} (recomendado: ${expected}) [${severity}]"
            ((WARNINGS++))
        fi
    fi
}

echo "--- Autenticación ---"
check_config "permitrootlogin" "no" "CRITICO"
check_config "passwordauthentication" "no" "CRITICO"
check_config "pubkeyauthentication" "yes" "CRITICO"
check_config "permitemptypasswords" "no" "CRITICO"

echo ""
echo "--- Configuración de red ---"
check_config "x11forwarding" "no" "MEDIO"
check_config "allowtcpforwarding" "no" "MEDIO"
check_config "gatewayports" "no" "MEDIO"
check_config "permittunnel" "no" "MEDIO"

echo ""
echo "--- Límites de conexión ---"
check_config "maxauthtries" "3" "ALTO"
check_config "logingracetime" "30" "MEDIO"
check_config "loglevel" "VERBOSE" "MEDIO"

echo ""
echo "--- Versión de OpenSSH ---"
SSH_VERSION=$(ssh -V 2>&1)
echo "[INFO] ${SSH_VERSION}"

echo ""
echo "============================================"
echo "  Resumen: ${ISSUES} fallos críticos, ${WARNINGS} avisos"
echo "============================================"

exit $ISSUES

Lista de verificación de hardening SSH

Antes de dar por terminada la configuración, repasa esta lista. La tengo impresa junto a mi escritorio y la uso cada vez que despliego un servidor nuevo:

  1. Autenticación: Deshabilitar login de root, eliminar contraseñas, usar solo claves Ed25519 o certificados.
  2. Criptografía: Configurar algoritmos post-cuánticos (mlkem768x25519-sha256), cifrados AEAD y MACs etm.
  3. Acceso: Definir AllowUsers/AllowGroups, implementar bastión SSH, configurar 2FA cuando sea posible.
  4. Protección contra fuerza bruta: Configurar Fail2Ban, limitar MaxAuthTries y MaxStartups, aplicar reglas de firewall.
  5. Auditoría: Activar LogLevel VERBOSE, configurar auditd, implementar registro de sesiones si lo requiere la normativa.
  6. Red: Deshabilitar X11Forwarding, AllowTcpForwarding y PermitTunnel (a menos que realmente los necesites).
  7. Mantenimiento: Actualizar OpenSSH regularmente, rotar claves y certificados, revisar la configuración al menos una vez al mes.
  8. Contenedores: Minimizar SSH en contenedores, endurecer SSH en nodos host, integrar con Vault para gestión de certificados a escala.

Conclusión

La seguridad SSH no es algo que configuras una vez y te olvidas. Es un proceso continuo que tiene que evolucionar al ritmo de las amenazas. La buena noticia es que en 2026, con la criptografía post-cuántica integrada en OpenSSH 10.0, la autenticación basada en certificados y herramientas como HashiCorp Vault, tenemos un arsenal bastante sólido para proteger nuestras conexiones.

Pero hay que usarlo. Las organizaciones que no actualicen sus configuraciones SSH se exponen a riesgos crecientes. Los ataques «almacenar ahora, descifrar después» hacen que incluso el tráfico cifrado con algoritmos clásicos sea potencialmente vulnerable a largo plazo.

Y recuerda: la seguridad es tan fuerte como su eslabón más débil. De nada sirve tener una configuración SSH perfecta si las claves de la CA están sin proteger o si los servidores llevan meses sin actualizaciones. Aplica estas prácticas de forma integral, automatiza las auditorías y mantén una cadencia regular de revisión. Tu yo del futuro te lo agradecerá.

Sobre el Autor Editorial Team

Our team of expert writers and editors.