Los pares de claves SSH tienen un problema de expansión descontrolada. Los certificados son la solución.

Los pares de claves SSH funcionan bien para tres servidores. Con treinta, se convierten en un riesgo de seguridad. Con trescientos, son una pesadilla de cumplimiento normativo. Las claves obsoletas se acumulan sin caducidad forzada, sin mecanismo de revocación central y sin un rastro de auditoría que vincule una clave con un evento de inicio de sesión específico. Los certificados SSH resuelven estos tres problemas sin cambiar nada en la forma en que los ingenieros se conectan a los servidores.

El problema de la proliferación de claves SSH

La vida media de una clave SSH en una organización con más de 100 ingenieros es de 4,3 años, según el estudio de Venafi sobre gestión de identidades de máquinas de 2024. Los ingenieros se incorporan, generan un par de claves, pegan su clave pública en authorized_keys en cada servidor que necesitan y, luego, nada cambia cuando se van. Las listas de comprobación de salida olvidan servidores. Las claves siguen vivas.

Los problemas estructurales de los pares de claves SSH a escala:

• Sin caducidad. Una clave creada en 2019 sigue siendo válida en 2026 a menos que alguien la elimine manualmente de cada archivo authorized_keys de cada servidor al que se añadió.
• Sin revocación central. Si una clave privada es robada o se pierde un portátil, revocar el acceso implica conectarse por SSH a cada servidor afectado y editar authorized_keys. En un entorno de 200 servidores, esto lleva horas, si es que siquiera sabes qué servidores tienen la clave.
• Sin rastro de auditoría. sshd registra la huella digital de la clave que autenticó una sesión, pero no hay un registro autoritativo que conecte esa huella con la identidad de un ingeniero específico en el momento de la emisión. Las huellas digitales de claves no son identidades.
• Riesgo de movimiento lateral. Una clave robada concede acceso a todos los servidores donde se añadió. No hay restricción de alcance, ni límite temporal, ni forma de limitar una clave a una IP de origen específica después de la emisión.

Nada de esto es hipotético. La brecha de Twitter de 2020 involucró a un interno que obtuvo acceso SSH mediante ingeniería social. La proliferación de claves hizo que acotar el incidente fuera mucho más difícil.

Cómo funcionan los certificados SSH

Una autoridad de certificación (CA) SSH no es más que un par de claves SSH, normalmente ed25519. En lugar de distribuir claves públicas de usuario a los servidores, configuras los servidores para que confíen en la clave pública de la CA. Luego, la CA firma las claves públicas de los usuarios individuales para producir certificados.

Un certificado SSH firmado incluye los siguientes campos:

• Principals: la lista de nombres de usuario o grupos para los que este certificado es válido (p. ej., alice, eng-team)
• Valid after / Valid before: marcas de tiempo fijas: el certificado es criptográficamente inválido fuera de esta ventana
• Restricción de dirección de origen: rango IP opcional desde el que se puede usar este certificado
• Extensiones: capacidades como permit-pty, permit-port-forwarding, permit-agent-forwarding; cada una puede concederse o denegarse por certificado
• Número de serie del certificado: un identificador único que aparece en los registros de autenticación de sshd

El sshd_config del servidor contiene una sola línea: TrustedUserCAKeys /etc/ssh/ca_user_key.pub. Ese es el único cambio de configuración necesario. Se acabó gestionar archivos authorized_keys.

Configurar tu propia CA en 15 minutos

No necesitas Teleport ni HashiCorp Vault para empezar. OpenSSH incluye todo lo necesario.

Paso 1 — Genera la clave de la CA en un host seguro:

ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "SSH User CA"

Mantén ca_user_key (privada) fuera de línea o en un gestor de secretos. Distribuye ca_user_key.pub a todos los servidores.

Paso 2 — Configura sshd en cada servidor:

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

Recarga sshd. El servidor aceptará cualquier certificado firmado por esta CA, sujeto a las restricciones de principal y validez.

Paso 3 — Emite un certificado a un usuario:

ssh-keygen -s ca_user_key -I "[email protected]" -n alice -V +8h alice.pub

Esto produce alice-cert.pub. La opción -I establece el ID de la clave (se registra en la autenticación), -n alice establece el principal, -V +8h lo hace válido durante 8 horas a partir de ahora.

Paso 4 — El usuario se conecta normalmente:

ssh alice@prod-server-01

OpenSSH presenta automáticamente el certificado junto con la clave privada. Sin cambios en el flujo de trabajo del usuario.

Certificados de corta duración + plataformas de identidad

La emisión manual de certificados funciona para equipos pequeños. Para producción a escala, necesitas emisión automatizada vinculada a tu proveedor de identidad.

Teleport actúa tanto como CA SSH como capa de proxy. Los ingenieros se autentican mediante SSO de Okta o Azure AD, Teleport emite un certificado de corta duración (12 horas por defecto) y se registra toda la actividad de la sesión. Revocar el acceso significa eliminar al usuario del grupo IdP, sin necesidad de cambios en los servidores.

El motor de secretos SSH de HashiCorp Vault proporciona la funcionalidad de CA sin la capa de proxy. Configura un rol de Vault:

vault write ssh/roles/eng-ssh \
  key_type=ca \
  allowed_users="*" \
  default_user=ubuntu \
  ttl=8h \
  max_ttl=24h \
  allowed_extensions="permit-pty,permit-port-forwarding"

Los ingenieros se autentican en Vault (mediante OIDC/Okta/Azure AD + MFA), solicitan un certificado con vault ssh -role eng-ssh -mode ca -mount-point ssh user@host y reciben un certificado con límite de tiempo. Vault registra cada emisión con la identidad solicitante.

AWS EC2 Instance Connect utiliza el mismo modelo de forma nativa para instancias EC2: envía una clave pública temporal (válida 60 segundos), conéctate, listo. Sin authorized_keys persistente.

La revocación de claves en cualquiera de estos sistemas es instantánea. Si la CA deja de emitir nuevos certificados a un usuario, todos sus certificados existentes caducan en cuestión de horas como máximo. Compáralo con buscar manualmente entradas de claves en cientos de servidores.

Certificados de host: la otra mitad

Los certificados SSH funcionan en ambas direcciones. Los certificados de usuario autentican a los usuarios frente a los servidores; los certificados de host autentican a los servidores frente a los usuarios.

Sin certificados de host, SSH usa TOFU (Trust On First Use): la primera vez que te conectas a un host, se te pide que aceptes su huella digital. Esto es vulnerable a ataques MITM mediante claves de host falsas, y la petición entrena a los ingenieros para ignorar las advertencias de seguridad.

Con una CA de host, firmas la clave de host de cada servidor:

ssh-keygen -s ca_host_key -I "prod-server-01" -h -n prod-server-01,10.0.1.5 -V +52w /etc/ssh/ssh_host_ed25519_key.pub

Añade la CA al known_hosts del cliente:

@cert-authority *.internal.example.com ssh-ed25519 AAAA... SSH Host CA

Ahora todos los servidores de tu flota son automáticamente de confianza para todos los clientes. Sin avisos de huella digital. Sin TOFU. Si un servidor se ve comprometido y su clave de host cambia, los clientes rechazarán la conexión de inmediato.

El rastro de auditoría que realmente obtienes

Con la autenticación basada en certificados, cada evento de inicio de sesión lleva un número de serie de certificado. Activa el registro detallado en sshd_config:

LogLevel VERBOSE

Las entradas del registro de autenticación ahora se ven así:

Accepted publickey for alice from 10.0.1.22 port 52341 ssh2: ED25519-CERT SHA256:... ID [email protected] (serial 42) CA ED25519 SHA256:...

El serial 42 se corresponde con una entrada específica del registro de emisión de Vault o con un evento de auditoría de Teleport que incluye el contexto completo de la identidad: quién solicitó el certificado, cuándo, desde qué IP, tras autenticarse con qué método MFA. Este es el rastro de auditoría que realmente necesitan las herramientas SIEM y los auditores de cumplimiento, no una huella digital de clave divorciada de cualquier identidad.

Ruta de migración

Migrar una flota existente es sencillo si se hace en orden:

• Audita primero. Ejecuta find / -name authorized_keys 2>/dev/null en toda tu flota (o usa una herramienta de gestión de configuración). Documenta cada clave, cuándo se añadió y quién es su propietario.
• Añade la confianza de la CA sin eliminar las claves existentes. Añade TrustedUserCAKeys a sshd_config en todos los servidores. La autenticación basada en claves existente sigue funcionando.
• Emite certificados a todos los ingenieros. Haz que cada ingeniero genere un nuevo par de claves y lo firme, o inscríbelos en Teleport/Vault para obtener emisión automatizada de certificados.
• Ejecuta en paralelo durante 30 días. Ambos métodos funcionan durante esta ventana. Supervisa los registros de autenticación para confirmar que todos los inicios de sesión en producción se realizan mediante certificados.
• Elimina las claves sin procesar. Después de 30 días de inicios de sesión limpios solo con certificados, elimina las entradas antiguas de authorized_keys.
• Clave de emergencia. Mantén un par de claves de larga duración en un cofre de secretos sellado (p. ej., HashiCorp Vault con política de emergencia) para acceso de emergencia si la CA no está disponible. Audita su acceso trimestralmente.

La migración no requiere tiempo de inactividad y los ingenieros apenas notan cambios en su flujo de trabajo diario, excepto que ya no reciben avisos de huella digital para servidores nuevos.

Conclusión

La autenticación SSH basada en certificados no es más compleja de usar que la basada en claves. Para los ingenieros, la experiencia es idéntica o más simple: sin distribución manual de claves, sin avisos de huella digital, sin "pega tu clave pública en este hilo de Slack". Para los equipos de seguridad, proporciona control central, revocación instantánea, caducidad forzada y un rastro de auditoría por sesión vinculado a identidades reales. Las herramientas (OpenSSH, Teleport, HashiCorp Vault, AWS EC2 Instance Connect) son maduras y están bien documentadas. Lo único que impide que la mayoría de los equipos migren es la inercia.