Hardening de SSH 2026: Algoritmos, Certificados y Bastion Hosts
Configuracion moderna de SSH con CA interna, algoritmos resistentes y bastion hosts auditables para reducir la superficie de ataque en entornos corporativos.
Cada vez que abrimos shodan.io y filtramos por port:22, encontramos cientos de miles de servidores aceptando todavia ssh-rsa con SHA-1, autenticacion por contrasena expuesta a internet y MACs como hmac-sha1. En 2026 esto no es configuracion heredada olvidada: es deuda tecnica que paga intereses en forma de incidente. El hardening de SSH dejo de ser un checklist de seis lineas en sshd_config y se convirtio en un pequeno subsistema que involucra CA interna, bastion auditable, rotacion de claves y telemetria centralizada. Este post muestra como el equipo Basilisk arma ese stack en laboratorio antes de llevarlo a produccion, con numeros concretos y herramientas que puedes probar hoy mismo.
Empieza por lo basico, pero hazlo bien. En un /etc/ssh/sshd_config moderno fuerza PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no y UsePAM yes. Para algoritmos, restringe KexAlgorithms a sntrup761x25519-sha512@openssh.com,curve25519-sha256, Ciphers a chacha20-poly1305@openssh.com,aes256-gcm@openssh.com y MACs a hmac-sha2-512-etm@openssh.com. sntrup761 ya entrega resistencia hibrida post-cuantica desde OpenSSH 9.0 y en 2026 no hay razon para no habilitarlo. Lanza ssh-audit contra el host antes y despues: la diferencia entre nota C+ y A es basicamente apagar diffie-hellman-group14-sha1 y similares. Tratalo como prerrequisito, no como entrega. Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion
El salto real de madurez llega al cambiar authorized_keys regados por una CA SSH interna. Generas un par de claves de CA (ed25519, sin passphrase solo si vive en un HSM o host offline), firmas certificados de usuario con TTL corto (4 a 12 horas) y distribuyes solo la clave publica de la CA via TrustedUserCAKeys en los servidores. El usuario se autentica con un certificado emitido por step-ca, Vault SSH o Teleport, atado al SSO corporativo. Resultado: revocar acceso a un ex empleado deja de ser cazar authorized_keys en 400 hosts y se convierte en simplemente no reemitir el certificado. En pentests internos, este unico cambio rompe la mitad de los caminos de movimiento lateral basados en claves huerfanas. Pentest de Active Directory: Kerberoasting Paso a Paso en Lab GOAD Movimiento Lateral en Lab: SMB, WMI y WinRM con Foco en Deteccion
El bastion host no debe ser un Linux cualquiera con SSH abierto. Pienselo como un proxy de identidad: recibe la conexion del usuario, valida el certificado contra la CA, registra la sesion completa (input y output) y abre un segundo SSH al objetivo via ProxyJump. Teleport, Boundary y la combinacion step-ca + auditd + tlog cubren ese caso. En una configuracion tipica que probamos para un cliente fintech, el bastion vivia en una VPC aislada con Security Group que solo permitia el puerto 22 desde la VPN corporativa, y los servidores internos rechazaban cualquier SSH que no viniera del CIDR del bastion. Eso colapsa la superficie de ataque de cientos de IPs a un unico punto monitoreado. Pivoting con Chisel y Ligolo-ng: Redes Segmentadas en Lab de Pentest
El logging centralizado cierra el ciclo. Habilita LogLevel VERBOSE en sshd, envia /var/log/auth.log via journald-remote o Fluent Bit hacia Elastic o Loki y crea reglas Sigma para detectar patrones como multiples fallos seguidos de exito, login con certificado por vencer en menos de una hora o ejecucion de comandos sospechosos via session recording. En una simulacion de red team nos tomo 11 minutos ser detectados intentando reutilizar una clave robada porque el principal del certificado no coincidia con el usuario del SSO. Sin esa correlacion, habrian sido dias. Quien ya escribio detecciones sabe que SSH es una de las fuentes mas ricas y mas subutilizadas. Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion Hunting de Living-off-the-Land Binaries en Windows con KQL
No olvides el lado cliente. Fuerza ~/.ssh/config con HashKnownHosts yes, VerifyHostKeyDNS yes cuando aplique, y usa ssh-agent con confirmacion por toque en una YubiKey (sk-ed25519). Para claves de servicio en pipelines, nada de claves estaticas en CI: emite certificados cortos via OIDC de GitHub Actions o GitLab hacia tu Vault. Eso elimina toda una clase de incidentes donde una clave filtrada en logs queda valida por anos. En paralelo, audita opciones: AllowAgentForwarding y StreamLocalBindUnlink casi siempre pueden apagarse. Supply Chain Security: Firma con Sigstore y SBOM Real en CI/CD Passwords y MFA: Migrando a Passkeys sin Romper tu Recuperacion
Takeaway practico: monta un laboratorio con tres VMs (CA + bastion + objetivo) usando step-ca, configura TTL de 8 horas, fuerza los algoritmos modernos, corre ssh-audit hasta sacar A y luego intenta autenticarte con una clave vieja. Si entras, tu configuracion aun no esta hardenizada. Repite el ejercicio una vez por trimestre, rota la clave de la CA anualmente y manten un runbook de emergencia para revocar y reemitir todo en menos de una hora. SSH sigue siendo la puerta favorita de los atacantes en 2026 precisamente porque lo tratamos como infraestructura invisible. Deja de tratarlo asi.