Claves SSH frente a certificados SSH: ¿Qué significa realmente la diferencia?

Las claves SSH y los certificados SSH autentican usuarios y sistemas mediante criptografía de clave pública , pero se basan en modelos de confianza fundamentalmente diferentes. Las claves SSH establecen la confianza colocando las claves públicas autorizadas en el archivo authorized_keys de cada servidor; los certificados SSH utilizan una Autoridad de Certificación (CA) de confianza para verificar identidades y otorgar acceso temporal de forma centralizada. Esta diferencia afecta a todas las etapas del ciclo de vida de las credenciales: cómo se otorga, gestiona, audita y revoca el acceso, especialmente a medida que los entornos crecen. La acción recomendada es: gestionar las claves SSH con un inventario, rotación y revocación centralizados para entornos donde las claves sean prácticas; evaluar la autenticación basada en certificados para entornos donde el inventario de claves haya crecido más allá de lo que la gestión manual puede controlar.

Respuesta rápida: Claves SSH frente a certificados SSH

Claves SSH: cada servidor confía de forma independiente en las claves públicas listadas en su archivo authorized_keys. Sin fecha de caducidad. Sin registro central. El acceso persiste hasta que se elimina manualmente de cada servidor. Certificados SSH: el servidor confía en una CA; la CA avala las identidades firmando certificados con ventanas de validez, nombres principales y restricciones opcionales. El acceso caduca automáticamente cuando finaliza la ventana de validez. La diferencia entre ambos no radica en la seguridad criptográfica, sino en cómo evoluciona el acceso con el tiempo a medida que se acumulan equipos, sistemas y credenciales. Para obtener el mapa de cumplimiento completo de la gestión de claves SSH, consulte Cumplimiento de la gestión de claves SSH . Para el marco de rotación, consulte Diseño de una política eficaz de rotación de claves SSH.

El problema de la acumulación: por qué importa la diferencia

El impacto operativo de estos diferentes modelos de confianza se hace evidente a medida que los entornos crecen. El problema no surge de un solo evento, sino que se acumula. Un ingeniero se incorpora y su clave se agrega a una docena de servidores. Un contratista finaliza su trabajo y su clave no se elimina porque nadie registró en qué servidores se encontraba. Las canalizaciones de automatización generan pares de claves que perduran más que las propias canalizaciones para las que fueron creadas. Tres años después, cientos de claves se encuentran dispersas por la infraestructura de servidores sin un inventario fiable de quién las posee.

Según un estudio del sector, el 57 % de las organizaciones consideraba que gestionar las claves SSH era una tarea tediosa y difícil. Si bien la concienciación ha mejorado, el riesgo operativo subyacente de las claves no gestionadas persiste, independientemente de si el problema se reconoce o no. Lo que dificulta su detección temprana es que no se observan fallos evidentes. Los servidores responden, los procesos se ejecutan y las implementaciones se completan. El problema de acceso es invisible hasta que se manifiesta como un incidente de seguridad o cumplimiento normativo.

Aquí es donde la distinción entre claves SSH y certificados SSH cobra importancia. Ambos proporcionan una autenticación sólida, pero sus modelos de confianza determinan cómo se mantiene, se extiende y se revoca dicha confianza con el tiempo. Comprender las diferencias estructurales permite a las organizaciones elegir el modelo adecuado para su entorno y nivel de madurez de gobernanza.

¿Qué son las claves SSH?

Una clave SSH es un par vinculado criptográficamente: una clave privada y una clave pública, generadas conjuntamente como un conjunto coincidente. Su único propósito es demostrar la identidad sin enviar una contraseña a través de la red.

La clave privada permanece en la máquina donde fue creada. Nunca debe copiarse, compartirse ni transferirse. Es el único archivo que puede completar una verificación de autenticación del servidor, y su seguridad es la base de la confianza.

La clave pública se distribuye a los servidores que requieren acceso. En cada servidor, se almacena en el archivo authorized_keys (normalmente ~/.ssh/authorized_keys para la cuenta de usuario de destino). Este archivo es una lista: una clave pública por línea, cada una representando una entidad que el servidor autenticará.

La seguridad reside en la criptografía asimétrica : la clave privada genera una firma criptográfica que solo la clave pública correspondiente puede verificar. Conocer una no permite deducir la otra; una firma válida solo puede ser producida por el poseedor de la clave privada.

Cómo funciona la autenticación mediante clave SSH

La secuencia de autenticación establece la identidad sin transmitir la clave privada:

1. La clave pública del usuario se coloca en el archivo authorized_keys del servidor de destino (por un administrador, por el usuario si tiene acceso al servidor o mediante aprovisionamiento automatizado).
2. El usuario inicia una conexión. SSH El cliente indica qué clave pública pretende utilizar para la autenticación.
3. El servidor comprueba su archivo authorized_keys. Si la clave pública enviada está presente y permitida para la cuenta de usuario de destino, el servidor procede con la autenticación.
4. El cliente firma la solicitud de autenticación con su clave privada y la envía al servidor. La clave privada nunca sale del cliente.
5. El servidor verifica la firma utilizando la clave pública almacenada. Una firma válida confirma que el cliente posee la clave privada correspondiente. La autenticación se realiza correctamente.

Modelo de confianza: el servidor confía en la clave SSH porque figura en el archivo authorized_keys. Esta confianza no tiene fecha de caducidad ni registro centralizado. Persiste hasta que alguien elimina manualmente la clave de dicho archivo en todos los servidores donde está implementada.

Los desafíos operativos de la gestión de claves SSH

El proceso de autenticación en sí es seguro. Los desafíos surgen de cómo se establece y se mantiene la confianza a gran escala:

• Cada servidor mantiene su propio archivo authorized_keys. Cada clave pública que necesite acceso debe agregarse, actualizarse o eliminarse individualmente en cada servidor.
• Las claves SSH no tienen fecha de caducidad. Una clave pública permanece segura hasta que se elimina manualmente de todos los servidores donde está instalada.
• Sin una centralizada inventarioLas organizaciones tienen dificultades para determinar quién es el propietario de una clave, por qué se implementó, si todavía está en uso y si debería seguir existiendo.
• Las claves creadas para proyectos temporales, contratistas o flujos de trabajo automatizados pueden permanecer activas mucho después de que haya finalizado su propósito, ampliando silenciosamente la superficie de ataque.

Estas limitaciones no son debilidades de la criptografía SSH. Son consecuencia de un modelo de confianza descentralizado en el que cada servidor decide de forma independiente en qué claves públicas confiar. A medida que los entornos crecen, las organizaciones buscan formas de centralizar las decisiones de confianza, reducir la administración manual y mejorar la visibilidad. Los certificados SSH se diseñaron para abordar estos desafíos operativos. Para obtener orientación relacionada sobre la gestión de claves SSH a gran escala, consulte Cómo la gestión de claves SSH refuerza la seguridad y Protección de claves SSH con HSM.

¿Qué son los certificados SSH?

Un certificado SSH es una clave pública firmada por una Autoridad de Certificación (CA) de confianza. La firma de la CA vincula la información de identidad y acceso a la clave, creando una credencial verificable con fecha de caducidad integrada. A diferencia de una clave pública independiente que no contiene información de propiedad, un certificado SSH incluye:

• ID de clave: Una cadena arbitraria asignada al momento de la firma que identifica el certificado en los registros y auditorías. Las organizaciones utilizan nombres de usuario, direcciones de correo electrónico, identificadores de empleados o números de ticket.
• Lista de directores: las identidades que el certificado está autorizado a representar. En el caso de los certificados de usuario, las entidades principales corresponden a nombres de usuario del sistema operativo, como ubuntu, ec2-user o admin.
• Período de validez: Se aplica una marca de tiempo de validez posterior y anterior (marcas de tiempo Unix) durante la autenticación. Si la hora actual queda fuera de este intervalo, el certificado se rechaza automáticamente.
• Extensiones: capacidades tales como permit-pty (acceso a terminal), permit-port-forwarding o permit-agent-forwarding.
• Opciones críticas: Se impusieron restricciones, como limitar el certificado a direcciones IP de origen específicas o restringir la sesión a un solo comando.
• Firma de CA: La firma criptográfica de la CA se aplica sobre todo lo anterior, impidiendo cualquier manipulación sin invalidar el certificado.

El formato de certificado SSH utilizado por OpenSSH no es el mismo que el formato X.509 utilizado para HTTPS. Se trata de un formato específico definido en la especificación OpenSSH PROTOCOL.certkeys. La CA en sí misma es simplemente un par de claves SSH almacenadas en una ubicación protegida: su clave privada firma los certificados de usuario y de host; su clave pública se distribuye una sola vez a cada servidor. A partir de ese momento, cualquier servidor configurado para confiar en la CA puede autenticar los certificados firmados por dicha CA.

Cómo funciona la autenticación mediante certificado SSH

La secuencia de autenticación difiere de la autenticación basada en claves en la forma en que se establece la confianza. En lugar de comprobar si la clave de conexión está listada en ese servidor específico, el servidor comprueba si el certificado fue firmado por una CA en la que confía:

1. Se genera un par de claves CA y su clave pública se distribuye a cada servidor una sola vez mediante la directiva TrustedUserCAKeys en sshd_config. Este es un paso de configuración que se realiza una sola vez por servidor; no es necesario realizar cambios al agregar o eliminar usuarios.
2. Cuando un usuario necesita acceso, su clave pública se envía a la CA para su firma. La CA la firma con su clave privada y devuelve un certificado que contiene la clave del usuario, su identidad, las entidades autorizadas y el período de validez. La clave privada del usuario permanece inalterable.
3. El usuario inicia la conexión. El cliente SSH presenta el certificado del usuario y demuestra que posee la clave privada firmando la solicitud de autenticación.
4. El servidor verifica la firma de la CA en el certificado utilizando la clave pública de la CA que ya posee desde el paso 1.
5. El servidor comprueba si el tipo de certificado es correcto para la autenticación del usuario.
6. El servidor comprueba si la hora actual se encuentra dentro del intervalo de validez posterior y anterior.
7. El servidor comprueba si al menos una entidad principal del certificado coincide con la cuenta de usuario de destino.
8. Si todas las comprobaciones son satisfactorias, el servidor verifica la firma del cliente. Una firma válida confirma que el cliente posee la clave privada correspondiente. Se concede el acceso.
9. Cuando expira el período de validez, el certificado deja de funcionar automáticamente. El usuario debe obtener un nuevo certificado firmado por la CA para recuperar el acceso. La clave privada permanece en posesión del cliente en ningún momento.

La diferencia estructural con la autenticación basada en claves radica en que el servidor no necesita un registro previo del usuario. La confianza fluye desde la CA, no desde un archivo en cada servidor individual.

Claves SSH frente a certificados SSH: una comparación directa

Dimensión	Las claves SSH	Certificados SSH
Modelo de confianza	Cada servidor confía directamente en las claves públicas individuales que aparecen en su archivo authorized_keys.	Cada servidor está configurado para confiar en una o más CA y acepta certificados firmados por esas CA.
Formato de credenciales	Clave pública independiente	Clave pública con metadatos firmados y firma de CA
La información de identidad	Campo de comentarios opcional; no se verifica durante la autenticación.	El ID de clave firmada y los principales están integrados en el certificado y se verifican durante la autenticación.
Vencimiento	No tiene fecha de caducidad predefinida; el acceso permanece válido hasta que la clave se elimine manualmente de cada servidor.	Periodo de validez predefinido que se aplica durante la autenticación; el certificado se rechaza automáticamente al cerrarse la ventana.
Aprovisionamiento de acceso	Las claves públicas deben distribuirse a cada servidor donde se requiera acceso.	Los servidores confían en la CA; los usuarios reciben certificados emitidos por la CA; no hay cambios por servidor cuando se agregan usuarios.
Eliminación de acceso	Las claves públicas deben eliminarse de todos los servidores donde se confíe en ellas; servidores que pueden pasar desapercibidos.	No renueve el certificado; el acceso caduca automáticamente. Es posible la revocación anticipada mediante la Lista de Revocación de Claves (KRL), pero requiere la distribución de la KRL a todos los servidores.
Rotación	Requiere generar un nuevo par de claves, distribuir la nueva clave pública y eliminar la clave antigua de todos los servidores.	Emitir un nuevo certificado; el par de claves subyacente puede reutilizarse si la política de la organización lo permite.
administración del servidor	Requiere mantener las entradas de authorized_keys en todos los servidores para todos los usuarios.	Requiere mantener la configuración de confianza de la CA una vez por servidor y gestionar la emisión de certificados.
Auditoría	Los registros muestran huellas digitales de las claves; la asignación de propiedad requiere registros externos; es difícil atribuirlas a individuos cuando las claves se comparten.	Los certificados incorporan atributos de identidad firmados, identificadores de clave y números de serie que mejoran la trazabilidad directamente en los registros de autenticación.
Escalabilidad organizacional	El esfuerzo de gestión crece linealmente con el número de usuarios, claves y servidores.	La gestión se orienta hacia la emisión centralizada de certificados y la gobernanza de las CA; la adición de usuarios no requiere cambios por servidor.
Requisitos de infraestructura	No se requiere infraestructura de CA	Requiere un par de claves de CA, un proceso de emisión de certificados y la distribución de la confianza de la CA a todos los servidores.
Postura de cumplimiento	Requiere una gestión activa de inventario, rotación y revocación para cumplir con los marcos de control de acceso.	Los registros de vencimiento integrados y de emisión centralizados generan de forma natural pruebas de cumplimiento; los certificados de corta duración reducen la carga administrativa de la revocación manual.
Caso de uso típico	Entornos pequeños y medianos, relaciones de acceso estáticas, implementaciones sencillas con gobernanza de claves activas.	Entornos a gran escala, gestión de acceso dinámico, gobernanza de identidad centralizada u organizaciones donde el inventario de claves SSH ha superado la capacidad de gestión manual.

Propiedad del ciclo de vida: Claves SSH frente a certificados SSH

Etapa del ciclo de vida	Claves SSH: ¿quién es el responsable?	Certificados SSH: ¿quién es el responsable?
Generation	Sistema de usuario o automatización; requiere la aplicación de políticas sobre la longitud del algoritmo y la clave.	El usuario envía la clave pública a la CA; la CA firma y devuelve el certificado; el algoritmo y la validez se rigen por la política de la CA.
Distribuidores	El administrador o una herramienta automatizada implementa la clave pública en el archivo authorized_keys de cada servidor autorizado.	El usuario recibe el certificado; los servidores no necesitan realizar cambios; la clave pública de la CA ya está distribuida.
Monitoring	Los registros de sesión muestran huellas digitales de claves; la asignación de propiedad requiere un inventario externo.	El ID de la clave del certificado y el número de serie aparecen en los registros; la identidad se puede atribuir directamente desde el registro.
Rotación	Se generó un nuevo par de claves; se implementó la nueva clave pública en todos los servidores; se eliminó la clave antigua de todos los servidores.	Se ha emitido un nuevo certificado; el certificado anterior caduca automáticamente; no es necesario realizar cambios en authorized_keys por servidor.
Revocación en el momento de la salida	La clave pública debe identificarse y eliminarse de todos los servidores; el lapso entre el inicio y la finalización constituye un riesgo de incumplimiento.	Deje de emitir certificados al usuario que se ha marchado; el certificado existente caduca dentro del período de validez; entrada KRL para revocación anticipada inmediata.
Pruebas de auditoría	Generado a partir de registros de sesión + inventario de claves externas; requiere correlación.	El registro de emisión de CA proporciona la atribución directamente; la ventana de validez proporciona evidencia automática del acceso con límite de tiempo.

¿Qué debería usar: claves SSH o certificados SSH?

Ninguno de los dos enfoques es universalmente superior. La elección correcta depende de la escala del entorno, la madurez de la gobernanza y la capacidad operativa.

• Las claves SSH son prácticas y seguras. En entornos pequeños y medianos donde se conoce el inventario de claves, se documenta a los propietarios, se aplica la rotación según un cronograma y la revocación se realiza de inmediato al momento de la salida, los requisitos de gobernanza para las claves SSH son manejables a esta escala cuando se cuenta con el respaldo de una plataforma de administración de claves SSH.
• Los certificados SSH se vuelven ventajosos. cuando: la organización no puede generar un inventario actualizado de todas las claves SSH bajo demanda; la gestión de archivos authorized_keys en cientos de servidores está generando inconsistencias; el tiempo transcurrido desde la salida de un empleado hasta la revocación completa de SSH es mayor de lo aceptable; las auditorías de cumplimiento están generando hallazgos sobre claves huérfanas o no rotadas; o el entorno está escalando más rápido de lo que la gestión manual de claves puede controlar.
• La transición puede ser gradual: Los servidores pueden confiar simultáneamente en las claves públicas tradicionales y en la CA durante la migración. Esto significa que las claves existentes siguen funcionando mientras se implementa la autenticación basada en certificados, lo que permite una migración gradual y de bajo riesgo.

Para las organizaciones que migran a certificados o modelos de acceso efímero, consulte Transformación de claves SSH estáticas en identidades de carga de trabajo de corta duración para conocer el marco de migración y el enfoque de identidad de carga de trabajo SPIFFE/SPIRE para cuentas de servicio.

Disparadores de rotación y revocación

• Salida de un empleado o cambio de puesto: En el caso de las claves SSH, elimine inmediatamente la clave pública de todos los servidores; en el caso de los certificados SSH, deje de emitir certificados y añada una entrada KRL para la revocación anticipada inmediata de cualquier certificado válido.
• Compromiso sospechado o confirmado: Para las claves SSH, revoque la clave en todos los servidores y genere una clave de reemplazo; para los certificados SSH, agregue una entrada KRL y vuelva a emitirlos desde la CA.
• Algoritmo obsoleto: Cualquier clave o certificado que utilice algoritmos obsoletos (DSA, RSA-1024) debe ser reemplazado. Para una comparación de algoritmos, consulte Comparación de claves SSH: RSA, DSA, ECDSA o EdDSA.
• Desmantelamiento del sistema: Elimine todas las autorizaciones de claves SSH para los sistemas dados de baja; para las implementaciones de certificados, actualice el archivo AuthorizedPrincipalsFile en los sistemas restantes.
• Compromiso de la clave privada de la CA: Para las implementaciones de certificados, este es el evento más crítico: la clave pública de la CA debe reemplazarse en cada servidor y todos los certificados emitidos anteriormente dejan de ser confiables. Proteja las claves privadas de la CA en los HSM para evitar este escenario.

Respuesta ante incidentes: Compromiso de clave SSH frente a compromiso de certificado SSH

• Clave SSH comprometida: Identificar todos los servidores con la clave pública en authorized_keys (requiere inventario); eliminar la clave pública de cada servidor; generar un nuevo par de claves; distribuir la nueva clave pública a los servidores autorizados; verificar que la autenticación de la nueva clave funcione; registrar todas las acciones con marcas de tiempo como evidencia de cumplimiento.
• Certificado SSH comprometido: Agregue el número de serie del certificado a la KRL; distribuya la KRL actualizada a todos los servidores inmediatamente; el certificado se rechazará en el siguiente intento de conexión; emita un nuevo certificado una vez que se resuelva el fallo en el manejo de credenciales; si la clave privada subyacente se ve comprometida, rote también el par de claves.
• Clave privada de CA comprometida (implementación de certificados): Generar un nuevo par de claves de CA; distribuir la nueva clave pública de CA a todos los servidores (reemplazando la entrada anterior de TrustedUserCAKeys); reemitir certificados para todos los usuarios desde la nueva CA; la clave pública de CA anterior se puede eliminar de los servidores una vez que todos los usuarios hayan migrado a la nueva CA. Este es el evento más grave; proteger las claves privadas de CA en los HSM para evitarlo.

Cómo puede ayudar la consultoría de cifrado

En Encryption Consulting, comprendemos los desafíos que enfrentan las empresas al administrar claves SSH a gran escala. SSH Secure proporciona seguridad integral del ciclo de vida de las claves, visibilidad centralizada y protección respaldada por HSM tanto para entornos de claves SSH como de certificados.

1. Visibilidad centralizada y mapeo de propiedad

El descubrimiento, tanto con agente como sin él, localiza todas las claves SSH en servidores y equipos de usuario. Todas las claves se almacenan en un inventario unificado con detalles de propiedad y uso, lo que elimina las claves huérfanas y garantiza la total transparencia en todo el entorno.

2. Orquestación automatizada del ciclo de vida de las claves

SSH Secure automatiza el ciclo de vida completo de las claves: generación segura, rotación basada en políticas y revocación. Las claves efímeras vinculadas a la sesión caducan automáticamente para operaciones sensibles, lo que garantiza el acceso con privilegios mínimos y asegura que las claves no persistan más allá de su uso previsto.

3. Protección integrada HSM

Todas las claves privadas se generan y almacenan dentro de los HSM , utilizando RSA-4096, ECDSA y Ed25519. El almacenamiento de claves privadas, no exportable y a prueba de manipulaciones, impide su extracción incluso en caso de que el sistema operativo del host se vea comprometido.

4. Control basado en políticas para operaciones clave

Todas las operaciones clave se rigen por controles basados ​​en políticas que garantizan la coherencia en todo el entorno, reducen los errores manuales y permiten el cumplimiento de los requisitos reglamentarios o los modelos de gobernanza internos.

5. Monitoreo continuo, auditoría y preparación para el cumplimiento

La monitorización en tiempo real con registro detallado de eventos, la integración con Splunk o Grafana Loki, los registros de auditoría descargables y los informes de cumplimiento proporcionan a los equipos de seguridad una visión clara del uso clave y de la postura general.

Conclusión

Las claves SSH y los certificados SSH resuelven el mismo problema de autenticación a nivel criptográfico. Ambos prueban la identidad sin transmitir una contraseña. La diferencia no radica en la robustez de la criptografía, sino en cómo evoluciona el acceso con el tiempo. Una clave colocada en un servidor hace tres años por alguien que ya no trabaja en la organización sigue siendo tan válida hoy como el día en que se añadió. El servidor no tiene forma de saber lo contrario. Esto no es un fallo de la clave, sino una consecuencia de un modelo de confianza descentralizado diseñado para la simplicidad.

La brecha radica en la gobernanza a lo largo del ciclo de vida de las credenciales. Para las organizaciones donde se conoce el inventario de claves SSH, se documenta la propiedad y se aplican consistentemente la rotación y la revocación, las claves SSH siguen siendo una opción segura y práctica. Para las organizaciones donde el inventario ha crecido más allá de lo que la gestión manual puede controlar, los certificados SSH ofrecen ventajas estructurales: caducidad integrada, registros de emisión centralizados y la eliminación de la gestión de authorized_keys por servidor. Fortalecer la gobernanza de las claves SSH mediante el descubrimiento centralizado, la asignación de propiedad, la rotación basada en políticas y la revocación oportuna es el paso más inmediato y práctico para asegurar el acceso privilegiado, independientemente de si se planea o no una migración a certificados. Para lecturas relacionadas, consulte Cumplimiento de la gestión de claves SSH , Por qué las claves SSH que nunca caducan representan un riesgo de seguridad y Transformación de claves SSH estáticas en identidades de carga de trabajo de corta duración.

Preguntas frecuentes

¿Cuál es la diferencia entre claves SSH y certificados SSH?

Las claves SSH establecen la confianza al colocar la clave pública del usuario en el archivo authorized_keys del servidor. Esta confianza no caduca ni requiere un registro central; se mantiene hasta que la clave se elimina manualmente de todos los servidores. Los certificados SSH utilizan una CA de confianza para verificar las identidades; el servidor confía en la CA, el certificado tiene un período de validez integrado y el acceso caduca automáticamente cuando finaliza dicho período.

¿Qué debo usar: claves SSH o certificados SSH?

Las claves SSH son prácticas cuando se conoce el inventario, se documenta la propiedad y se aplica una gobernanza activa. Los certificados SSH son ventajosos cuando el inventario de claves ha crecido más allá del seguimiento manual, la revocación es lenta o las auditorías de cumplimiento están generando observaciones. La transición puede ser gradual: los servidores pueden confiar en ambos modelos simultáneamente durante la migración.

¿Los certificados SSH caducan automáticamente?

Sí. Los certificados SSH incluyen un período de validez (marcas de tiempo de validez posterior y anterior) que se aplica durante la autenticación. Si la hora actual queda fuera de este período, el certificado se rechaza independientemente de la confianza previa. Las claves SSH no tienen fecha de caducidad; permanecen seguras hasta que se eliminan manualmente de authorized_keys en cada servidor.

¿Cómo se revoca un certificado SSH antes de que caduque?

Mediante una Lista de Revocación de Claves (KRL): el administrador de la CA agrega el número de serie del certificado o la huella digital de la clave a la KRL; cada servidor verifica la KRL mediante la directiva RevokedKeys de sshd_config. Limitación: la KRL debe distribuirse a todos los servidores antes de que la revocación surta efecto. Los certificados de corta duración reducen este problema: un certificado válido por ocho horas caduca antes de que surja la mayoría de las necesidades de revocación.

¿Cuál es el coste operativo de implementar una CA SSH?

Única vez: generar un par de claves de CA; distribuir la clave pública de CA a todos los servidores mediante TrustedUserCAKeys. Proteger la clave privada de CA en el HSM para entornos de alta seguridad. Continuo: gestionar la emisión de certificados (integrarse con proveedores de identidad, establecer entidades principales y periodos de validez); rotación de claves de CA según un calendario plurianual; gestión de KRL para la revocación anticipada. A cambio: eliminar la gestión de authorized_keys por servidor para todos los usuarios cubiertos por certificados.

¿Los certificados SSH son iguales que los certificados TLS?

No. Los certificados SSH utilizan el formato OpenSSH PROTOCOL.certkeys (específico de SSH), no X.509 (utilizado para TLS/HTTPS). Ambos emplean una CA que avala una clave pública, pero sus formatos son estructuralmente diferentes y no intercambiables. Una CA SSH es simplemente un par de claves SSH, no una CA X.509.