Administrás 200 servidores Linux con SSH expuesto a varios equipos. ¿Cómo diseñás un acceso seguro, auditable y fácil de revocar?
$ interview --rol redes
Evalúa el criterio de hardening a escala: autenticación fuerte, bastión, certificados SSH, mínimo privilegio, auditoría, revocación y detección de abuso.
El objetivo es no depender de claves sueltas en authorized_keys, que nadie sabe revocar a tiempo.
1. Exposición de red
SSH no queda abierto a internet. Se accede por un bastión o por un acceso con VPN/zero trust. Los servidores solo aceptan el puerto 22 desde el bastión, con firewall o security groups.
Uso ProxyJump para no copiar claves privadas en el bastión.
2. Autenticación
Código: text
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/principals/%u
Uso una CA SSH que firma certificados de usuario de corta duración (por ejemplo, 8 horas) tras un login con SSO+MFA. Hay herramientas como Vault, step-ca o Teleport que lo resuelven.
Si alguien se va, se lo deshabilita en el IdP y su certificado expira solo. Para casos urgentes existe RevokedKeys.
También firmo las claves de host para eliminar el "trust on first use".
3. Autorización
Los principals se mapean a roles (por ejemplo, web-ro o db-admin). Configuro sudo con reglas mínimas, nada de ALL para todos, y cuentas nominales en vez de usuarios compartidos.
4. Auditoría y detección
Envío los logs de sshd, sudo y auditd a un SIEM central, con el ID del certificado en cada sesión. Si se requiere, también grabo las sesiones en el bastión.
Configuro alertas para logins fuera del bastión, picos de fallos, uso de root, cambios en sshd_config y claves nuevas en authorized_keys.
Aplico rate limiting o fail2ban como capa extra, no como defensa principal.
5. Operación
Toda la configuración se gestiona con Ansible y se valida con Código: bash
sshd -t
antes de recargar. Mantengo un acceso de emergencia (break-glass) documentado y probado, y reviso periódicamente los algoritmos con ssh-audit. El despliegue es gradual, para no dejarme afuera de toda la flota.
Errores comunes
Proponer solo cambiar el puerto o instalar fail2ban como solución principal. Seguir distribuyendo claves estáticas sin caducidad ni proceso de revocación. Aplicar cambios de sshd a toda la flota sin probar y sin tener un acceso de emergencia.
Redactado con el asistente Underc0de IA. Actualizado el 15/11/2026. ¿Ves un error? Contanos en el foro.
