Hardening de SSH 2026: Algoritmos, Certificados y Bastion Hosts

Cada vez que abrimos shodan.io y filtramos por port:22, seguimos encontrando cientos de miles de servidores aceptando ssh-rsa con SHA-1, autenticacion por contrasena expuesta directo 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 con CA interna, bastion auditable, material de clave de corta vida y telemetria centralizada. Esta guia recorre todo el stack tal como lo arma el equipo Basilisk en laboratorio antes de llevarlo a produccion, con configuracion concreta, comandos reales y los modos de fallo que vemos una y otra vez.

Por que SSH sigue siendo la puerta favorita del atacante

SSH es el protocolo de administracion remota de practicamente todo Linux y de la mayoria del equipamiento de red, lo que lo convierte en la credencial de mayor valor del parque. Los atacantes lo aman porque una unica clave o contrasena valida entrega una shell interactiva con los privilegios de la cuenta objetivo, sin cadena de exploits. Las tres causas raiz recurrentes son: claves reutilizadas o nunca rotadas que sobreviven al empleado que las creo; autenticacion por contrasena atacada por fuerza bruta desde botnets; y el downgrade a algoritmos debiles que permite a un atacante de red manipular el handshake. Trata a SSH como un sistema de identidad, no como una utilidad. Cada decision de diseno de abajo reduce una de esas tres clases, y el orden importa: arregla la autenticacion antes que la telemetria, porque registrar una brecha que no puedes prevenir solo te dice cuando perdiste.

Base de sshd_config que no se negocia

Empieza por el daemon del servidor. En un /etc/ssh/sshd_config moderno fuerza PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no, UsePAM yes y PermitEmptyPasswords no. Agrega MaxAuthTries 3, LoginGraceTime 20 y ClientAliveInterval 300 para que las sesiones semiabiertas mueran. Limita el alcance con AllowGroups ssh-users en vez de permitir cada cuenta local. Valida el archivo antes de recargar con sshd -t, y nunca edites el puerto en vivo sin una segunda sesion abierta, porque un error de tipeo en un bloque Match puede dejarte fuera. Estas directivas son el piso: ninguna cuesta nada y todas eliminan una primitiva de ataque.

Algoritmos modernos e intercambio de claves post-cuantico

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,hmac-sha2-256-etm@openssh.com. El hibrido sntrup761 entrega resistencia post-cuantica desde OpenSSH 9.0, y en 2026 no hay razon para no habilitarlo: protege el trafico capturado hoy contra el descifrado cuantico de manana, el problema harvest-now-decrypt-later. Corre ssh-audit contra el host antes y despues. La diferencia entre nota C+ y A es basicamente apagar diffie-hellman-group14-sha1, cifrados CBC y MACs truncados. Prefiere las variantes etm (encrypt-then-MAC) porque autentican el texto cifrado, no el texto plano. Trata pasar ssh-audit como prerrequisito, no como entrega.

Reemplazar claves regadas por una CA SSH interna

El salto real de madurez llega al jubilar los archivos authorized_keys y emitir certificados. Genera un par de claves de CA (ssh-keygen -t ed25519 -f ssh_user_ca) cuya mitad privada solo viva en un HSM o firmante offline, y firma certificados de usuario con TTL corto de 4 a 12 horas: ssh-keygen -s ssh_user_ca -I alice@corp -n alice -V +8h user_key.pub. En cada servidor distribuyes solo la clave publica de la CA via TrustedUserCAKeys /etc/ssh/ca.pub. El usuario se autentica con un certificado emitido por step-ca, HashiCorp Vault SSH o Teleport, atado al SSO corporativo. Revocar acceso a un ex empleado deja de ser cazar claves en 400 hosts y se vuelve simplemente no reemitir el certificado. En pentests internos, este unico cambio rompe la mitad de los caminos de movimiento lateral basados en claves huerfanas, porque la clave robada no vale nada una vez que su certificado expira.

El bastion como proxy de identidad, no como jump box

Un bastion endurecido no es 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, HashiCorp Boundary y la combinacion step-ca + auditd + tlog cubren ese caso. En una configuracion tipica 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 alcanzables desde internet a un unico punto monitoreado donde cada pulsacion queda registrada y cada sesion es atribuible a una identidad humana.

Endurecimiento del lado cliente y claves respaldadas por hardware

No olvides el cliente. Fuerza ~/.ssh/config con HashKnownHosts yes, VerifyHostKeyDNS yes cuando aplique, y genera una clave respaldada por hardware con ssh-keygen -t ed25519-sk para que la mitad privada nunca salga de una YubiKey y cada autenticacion requiera un toque fisico. Corre ssh-agent con confirmacion (ssh-add -c) para que una workstation comprometida no reutilice el socket del agente en silencio. Deshabilita opciones que no necesitas: AllowAgentForwarding no y AllowTcpForwarding no en el servidor salvo que un flujo documentado lo exija, porque el agent forwarding hacia un host no confiable permite a ese host secuestrar tu agente mientras el socket este vivo.

CI/CD y claves de servicio sin secretos de larga vida

Las identidades de maquina suelen ser el lugar donde el acceso humano endurecido se vuelve a filtrar. Prohibe claves estaticas en CI. En su lugar, emite certificados cortos via OIDC de GitHub Actions o GitLab contra tu Vault, de modo que un pipeline reciba un certificado valido por minutos, acotado al host exacto que debe alcanzar. Eso elimina toda la clase de incidentes donde una clave filtrada en un log queda valida por anos. Para destinos de deploy, usa bloques Match que aten un certificado de servicio a un unico comando con ForceCommand y PermitOpen, convirtiendo una shell general en una accion estrecha y auditable que no puede reconvertirse en acceso interactivo.

Logging centralizado y detecciones que de verdad disparan

El logging cierra el ciclo. Habilita LogLevel VERBOSE en sshd para registrar fingerprints de clave, envia /var/log/auth.log via journald-remote o Fluent Bit hacia Elastic o Loki, y escribe reglas Sigma para los patrones que importan: fallos repetidos seguidos de exito desde el mismo origen, login con un certificado que expira en menos de una hora, un principal de certificado que no coincide con el usuario del SSO, o comandos sospechosos capturados por session recording. En una simulacion de red team nos tomo 11 minutos ser detectados reutilizando una clave robada precisamente porque el principal del certificado no coincidia con la identidad del SSO y la regla de correlacion alerto. Sin esa correlacion, habrian sido dias. SSH es una de las fuentes de telemetria mas ricas y subutilizadas que posees.

Trampas comunes que anulan tu hardening en silencio

Los errores recurrentes: dejar PermitRootLogin prohibit-password y darlo por hecho mientras una clave root compartida sigue existiendo; endurecer el daemon pero dejar ~/.ssh/authorized_keys escribible por el usuario, de modo que cualquier ejecucion de codigo reagregue una clave; olvidar que los bloques Match se evaluan de arriba hacia abajo y un match amplio temprano oculta uno estricto posterior; y rotar host keys sin actualizar la distribucion de known_hosts, lo que entrena a los usuarios a ignorar advertencias de host key. Otro asesino silencioso es un MaxStartups sin limite que deja que una avalancha de conexiones agote el daemon. Audita esto de forma explicita; ninguno aparece como error, solo dejan la puerta entreabierta.

Checklist de hardening

Antes de declarar un host endurecido, verifica: nota A en ssh-audit; auth por contrasena y teclado-interactivo deshabilitada; login root apagado; solo KEX, cifrado y MAC modernos; certificados emitidos por CA con TTL bajo 12 horas; TrustedUserCAKeys configurado y sin authorized_keys perdidos; ingreso solo por bastion forzado a nivel de red; session recording activo; logs VERBOSE enviados y al menos tres reglas Sigma vivas; claves de cliente respaldadas por hardware; sin claves estaticas en CI; y un runbook de emergencia que revoque y reemita toda la flota en menos de una hora. Si alguna linea queda sin marcar, el host no esta listo.

FAQ: Es SSH con certificados exagerado para un equipo pequeno?

No. Incluso con cinco ingenieros, una CA interna elimina el peor riesgo operativo, las claves huerfanas, y se monta en una tarde con step-ca. El punto de equilibrio no es el tamano de la flota, es el momento en que una segunda persona necesita acceso a un segundo host, porque ahi la gestion manual de authorized_keys empieza a derivar. Empieza con un TTL de 8 horas atado a tu proveedor de identidad y crece desde ahi.

FAQ: Habilitar sntrup761 rompe clientes viejos?

Los clientes con OpenSSH anterior a 9.0 no negocian el KEX hibrido y simplemente caen a curve25519-sha256, por eso lo mantienes en la lista. La respuesta practica es actualizar clientes: cualquier workstation aun en un OpenSSH previo a 9.0 esta atrasada en parches por otras razones. Manten el KEX post-cuantico primero en el orden de preferencia para que los clientes modernos lo obtengan automaticamente.

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 cada trimestre, rota la clave de la CA anualmente y manten probado el runbook de emergencia. SSH sigue siendo la puerta favorita de los atacantes en 2026 precisamente porque lo tratamos como infraestructura invisible. Deja de tratarlo asi.