Por qué las claves SSH estáticas son un riesgo y cómo las claves SSH efímeras lo solucionan.

La gestión de claves SSH se ha convertido en una de las áreas más importantes y menos reguladas de la seguridad empresarial. Los pares de claves SSH estáticas han sido la base del acceso remoto seguro durante décadas y siguen estando profundamente integrados en la infraestructura de la mayoría de las organizaciones. Las características que las hacen convenientes a pequeña escala, en concreto su persistencia y la ausencia de un mecanismo de caducidad, generan riesgos de seguridad que se agravan a medida que los entornos crecen.

A diferencia de las contraseñas que caducan según un calendario predefinido, o de los certificados TLS que los navegadores rechazan una vez expirada su fecha de validez, una contraseña estática... Clave SSH No tiene fecha de caducidad predefinida. Una vez que una clave pública se coloca en un archivo authorized_keys en un servidor, otorga acceso indefinidamente hasta que alguien la elimine explícitamente. En entornos con cientos de ingenieros, miles de servidores y sistemas automatizados que generan claves en todas las capas de la infraestructura, este paso de eliminación explícita se omite sistemáticamente.

Un análisis de más de 14 millones de claves de cliente SSH en entornos empresariales reveló que la organización grande promedio posee más de 7,000 claves huérfanas de acceso de administrador, al menos una por servidor analizado. Estas claves, con el máximo nivel de acceso al sistema, pertenecen a identidades que ya no existen en la organización y permanecen latentes en la infraestructura de producción. El mismo análisis halló que muchas organizaciones han acumulado claves SSH en una proporción de diez a uno con respecto al número de empleados, lo que refleja la prolífica creación de claves y la poca frecuencia con la que se eliminan.

Las claves efímeras solucionan este problema a nivel arquitectónico. En lugar de crear un par de claves permanente que persiste hasta su revocación manual, las claves efímeras se generan bajo demanda para una sesión o ventana operativa específica y se invalidan automáticamente al finalizar dicha sesión. No existe acceso permanente, ni credenciales huérfanas, ni pasos de revocación que puedan pasarse por alto. Este blog analiza los modos de fallo específicos de las claves SSH estáticas, explica el mecanismo técnico de emisión de claves efímeras y describe cómo las organizaciones pueden iniciar la transición sin interrumpir la infraestructura existente.

Cómo funciona la autenticación con clave pública SSH y dónde falla.

La autenticación mediante clave pública SSH se define en la RFC 4252, Sección 7. Se trata de un mecanismo basado en firmas, en lugar de un sistema de desafío-respuesta emitido por el servidor. El cliente envía un mensaje SSH_MSG_USERAUTH_REQUEST que incluye el nombre de usuario, el nombre del servicio, el nombre del método ("publickey"), el algoritmo de clave pública y la clave pública en sí. Opcionalmente, el cliente puede enviar primero la solicitud con el indicador de firma desactivado; si el servidor acepta la clave, responde con SSH_MSG_USERAUTH_PK_OK y el cliente procede con la solicitud firmada.

Al enviar la solicitud con la opción de firma activada, el cliente firma un bloque de datos definido que consiste en el identificador de sesión concatenado con los campos de la solicitud, utilizando la clave privada correspondiente. El servidor verifica la firma con la clave pública que figura en el archivo authorized_keys para el usuario de destino. Si la verificación es exitosa, el cliente ha demostrado que posee la clave privada sin transmitirla.

La clave privada en sí no se transmite por la red; según la configuración del cliente, puede residir en un agente SSH en la memoria del cliente, en un archivo de claves cifrado en disco o en un dispositivo de hardware como un dispositivo FIDO2 o una tarjeta inteligente, del cual nunca sale. Este es un protocolo criptográfico bien diseñado. El problema de seguridad no reside en el protocolo de enlace en sí, sino en qué sucede con las claves después de su creación y cuánto tiempo permanecen en los archivos authorized_keys.

Las claves SSH no caducan.

Una clave SSH estática no tiene período de validez. Una vez añadida a authorized_keys, autoriza el acceso indefinidamente. No existe un equivalente a una certificados digitales campo notAfter y no Autoridad certificada que emite recordatorios de renovación. Los estudios del sector indican que, en la mayoría de las grandes organizaciones, la mayoría de las claves autorizadas están inactivas, pero aún así otorgan acceso en tiempo real.

La extracción de llaves depende de procesos manuales que fallan sistemáticamente.

Una encuesta realizada a más de 550 CIOs de organizaciones de seguridad empresarial reveló que el 96 % cuenta con políticas de seguridad que exigen la eliminación de la clave SSH cuando un empleado es despedido o cambia de puesto. Sin embargo, el 40 % de esas mismas organizaciones reconoce no disponer de herramientas automatizadas para garantizar dicha eliminación. En teoría, la brecha entre la política y la ejecución se subsana mediante pasos manuales de desvinculación que requieren que una persona recuerde eliminar una clave específica de cada servidor al que tenga acceso. En entornos con cientos de servidores y poblaciones de claves acumuladas y distribuidas entre varios equipos, este proceso suele fallar.

Una clave comprometida sigue siendo válida hasta que se descubra.

Si un atacante obtiene una clave privada SSH estática mediante phishing, un secreto de canalización CI/CD expuesto o un repositorio de código subido accidentalmente, esa credencial sigue siendo totalmente válida hasta que alguien descubra la vulneración y elimine todas las claves públicas correspondientes de todos los archivos authorized_keys en toda la flota.

El informe CrowdStrike Global Threat Report 2025 reveló que el 79 % de los ciberataques en 2024 no utilizaron malware, sino credenciales válidas. Una clave SSH robada pertenece precisamente a esta categoría: legítima, de confianza para los sistemas objetivo e invisible para las herramientas de detección basadas en firmas.

Las claves SSH no generan ningún registro de auditoría a nivel de identidad.

La autenticación estándar mediante clave SSH registra únicamente la dirección IP de origen y la huella digital de la clave. No registra quién utilizó la clave, si su uso cumplió con las políticas ni qué comandos se ejecutaron durante la sesión. Según el requisito 8 de PCI-DSS, los controles NIST 800-53 AU y el anexo A.9 de ISO 27001, esta falta de trazabilidad a nivel de identidad representa una brecha de gobernanza que se vuelve más difícil de subsanar a medida que aumenta el inventario de claves.

Por qué la proliferación de claves SSH se agrava con el tiempo.

La proliferación de claves SSH no es un problema que se estabilice a ninguna escala. Cada nuevo despliegue de servidor crea nuevos archivos authorized_keys. Cada desarrollador que se incorpora a la organización genera un par de claves. Cada canalización de CI/CD que se despliega en la infraestructura crea una clave de servicio. Cada contrato con un proveedor externo añade claves a los sistemas a los que accede. Con el tiempo, en una gran empresa típica, la relación entre una clave y la identidad o el sistema al que pertenece se vuelve cada vez más opaca.

Un estudio realizado en diversos entornos empresariales reveló que entre el 60 y el 90 por ciento de las organizaciones carecen de un inventario completo de sus claves SSH activas. Esto no se debe principalmente a una falta de disciplina organizativa, sino a un diseño que no se concibió para la escala y la velocidad de la infraestructura moderna. SSH se desarrolló a mediados de la década de 1990, cuando su uso típico era el de un administrador de sistemas que gestionaba un pequeño conjunto de servidores; SSH-2 se estandarizó formalmente como protocolo IETF en 2006 (RFC 4250–4254).

El archivo authorized_keys era una solución a escala humana. A escala empresarial, con cientos de servidores, infraestructura dinámica y pipelines de CI/CD que generan claves continuamente, se convierte en un almacén de credenciales inmanejable sin controles de ciclo de vida integrados. Las consecuencias, tanto de seguridad como financieras, están bien cuantificadas.

El informe de IBM sobre el costo de una filtración de datos en 2025 sitúa el promedio mundial en 4.44 millones de dólares, con un promedio de 4.67 millones de dólares para las filtraciones iniciadas mediante credenciales robadas, que tardan 246 días en identificarse y contenerse, uno de los ciclos de vida más largos de cualquier vector de ataque. El informe de Verizon sobre investigaciones de filtraciones de datos de 2025 reveló que las credenciales robadas fueron el principal vector de acceso inicial en el 22 % de todas las filtraciones, más que cualquier otra categoría de ataque. Las claves SSH, que son persistentes, tienen amplios privilegios y a menudo no se supervisan, son precisamente el tipo de credenciales que permite estas estadísticas.

Cómo funcionan las claves SSH efímeras: el mecanismo técnico

Las claves SSH efímeras son pares de claves criptográficas de corta duración que se generan bajo demanda para una sesión específica y se invalidan automáticamente al finalizar dicha sesión. La ventaja de seguridad sobre las claves estáticas no reside en el algoritmo, que es idéntico, sino en su ciclo de vida. Una clave SSH efímera se crea para un propósito específico y deja de ser válida una vez que dicho propósito se ha cumplido.

El mecanismo mediante el cual las claves SSH efímeras se entregan a un servidor de destino varía según la implementación. Los dos enfoques más comunes son la gestión dinámica de authorized_keys y Autenticación basada en certificados OpenSSH, cada una con sus propias ventajas e inconvenientes en materia de seguridad y funcionamiento.

Gestión dinámica de claves autorizadas

La plataforma de gestión de claves genera un nuevo par de claves al solicitar la sesión. La clave pública se guarda en el directorio authorized_keys del servidor de destino solo durante la sesión y se elimina inmediatamente al finalizar la misma o al expirar su validez. El usuario no necesita realizar ninguna limpieza. Este método funciona con configuraciones estándar de OpenSSH sin agentes adicionales en los hosts de destino.

Autenticación basada en certificados OpenSSH

OpenSSH admite un Autoridad certificada modelo (definido en la especificación OpenSSH PROTOCOL.certkeys, con tipos de certificados específicos del algoritmo, como [email protected] y el [email protected]) en el que una CA de confianza firma certificados de usuario de corta duración que el servidor SSH acepta en lugar de las entradas individuales de authorized_keys. El servidor confía en cualquier certificado firmado por la CA durante el período de validez del mismo, que puede configurarse en minutos.

Cuando el certificado caduca, el acceso se revoca automáticamente. Este método requiere configurar el servidor SSH para que confíe en la clave pública de la CA mediante la directiva TrustedUserCAKeys, pero elimina la gestión de authorized_keys por servidor. Además, ofrece una escalabilidad significativamente mejor en grandes flotas de servidores.

En ambos modelos, la solicitud de sesión inicia un nuevo ciclo de verificación: autenticación de identidad, evaluación de políticas y emisión de claves dentro del período de tiempo autorizado. Al finalizar la sesión, finaliza el acceso. No se requiere ninguna limpieza en el servidor de destino más allá de la que gestiona automáticamente la plataforma.

Comparación directa: Claves SSH estáticas frente a claves efímeras

Atributo	Claves SSH estáticas	Claves efímeras
Expiración	Potencialmente indefinido; válido hasta su revocación manual.	Caduca automáticamente al final de la sesión o ventana.
Revocación	Eliminación manual en todos los archivos authorized_keys	No se requiere ningún paso de revocación; la invalidación es automática.
Modelo de autenticación	La confianza se establece una sola vez al crear la clave; se reutiliza para siempre.	La confianza se verifica nuevamente en cada solicitud de sesión.
Registro de auditoría	Solo IP y huella digital de clave; sin trazabilidad de identidad.	Registro completo de la sesión vinculado a una identidad verificada
Acceso de pie	Sí, persistente independientemente de los cambios de política o de funciones.	No, el acceso existe solo para la sesión autorizada.
Ventana de movimiento lateral	Potencialmente indefinido si la clave no se detecta.	De minutos a horas, delimitado por la ventana de sesión.
desvinculación	Extracción manual de la llave; frecuentemente incompleta	El acceso finaliza automáticamente; no se requiere limpieza por servidor.

Claves SSH efímeras y arquitectura de confianza cero

La arquitectura de confianza cero, tal como se define en la publicación especial 800-207 del NIST, exige que cada solicitud de acceso se autentique y autorice conforme a la política vigente en el momento de la solicitud, y no en función de una relación de confianza establecida previamente. Requiere una verificación continua, no una confianza implícita basada en accesos anteriores.

Las claves SSH estáticas son estructuralmente incompatibles con este requisito. Establecen la confianza una sola vez al crear la clave y la mantienen indefinidamente, independientemente de los cambios en la situación laboral del usuario, la configuración del dispositivo o la política de acceso actual. Su modo de funcionamiento predeterminado es el acceso permanente, sin verificación.

Las claves SSH efímeras se ajustan al principio de Confianza Cero por diseño. Cada solicitud de sesión activa una nueva verificación de identidad y evaluación de políticas. El acceso se concede solo cuando todas las comprobaciones se superan, únicamente durante el tiempo autorizado, y finaliza automáticamente cuando se cumple dicho plazo. No existe ningún privilegio permanente que pueda comprometerse ni ninguna credencial persistente que pueda robarse.

El informe global de amenazas de CrowdStrike de 2026 reveló que el tiempo promedio de fuga de ciberdelincuencia se redujo a 29 minutos en 2025, con la fuga más rápida observada en tan solo 27 segundos; en una intrusión, la exfiltración de datos comenzó a los cuatro minutos del acceso inicial. Una clave SSH estática que persiste durante años les da a los atacantes todo el tiempo que necesitan. Una clave SSH efímera válida durante minutos no. Por eso las organizaciones que adoptan Marcos de seguridad de confianza cero Cada vez más, consideran la gestión de claves SSH como un pilar fundamental de su estrategia de acceso privilegiado.

Consideraciones de Seguridad

La gestión de claves SSH efímeras mejora sustancialmente la seguridad del acceso SSH. Su implementación introduce sus propios requisitos, que deben cumplirse para garantizar la solidez de la arquitectura.

• Seguridad de la plataforma de emisión: La plataforma centralizada de emisión de claves es un componente de seguridad fundamental. Debe ser robusta, altamente disponible y estar gestionada con el mismo rigor que cualquier sistema privilegiado. Una vulneración de la plataforma de emisión tiene consecuencias más graves que una vulneración de claves estáticas individuales, ya que afecta a todas las sesiones en lugar de a una sola credencial.
• Material clave que solo debe memorizarse: El material de clave efímera en el lado del cliente debe existir únicamente en memoria durante la sesión. Cualquier implementación que escriba la clave privada en el disco reintroduce el riesgo de persistencia que las claves SSH efímeras están diseñadas para eliminar. Verifique que el cliente realice un borrado explícito de la memoria al finalizar la sesión.
• Dimensionamiento de la ventana de validez: Los periodos de validez deben ajustarse a las necesidades operativas reales, en lugar de utilizar un valor predeterminado. Una tarea de mantenimiento de 20 minutos no debería tener una clave válida durante 8 horas. Revise periódicamente la configuración de los periodos de validez y exija una justificación explícita para las solicitudes de acceso extendido.
• Monitoreo de tuberías: Supervise el proceso de emisión en busca de patrones anómalos: picos de volumen, acceso desde direcciones de origen inesperadas o solicitudes fuera del horario laboral habitual. Estas son señales importantes, incluso cuando las decisiones de acceso individuales parecen técnicamente válidas, ya que pueden indicar una posible vulneración de la cuenta.
• Corrección de clave estática paralela: Las claves estáticas heredadas no deben permanecer en authorized_keys junto con el nuevo flujo de trabajo de claves efímeras. La detección y corrección del conjunto de claves existente debe realizarse en paralelo con la adopción de claves SSH efímeras. Un estado híbrido sin un cronograma de corrección anula gran parte de la mejora de seguridad.

Cómo SSH Secure implementa la gestión de claves SSH efímeras

At Consultoría de cifradoEntendemos los desafíos que enfrentan las empresas al administrar claves SSH a gran escala. Nuestra solución, SSH seguroEstá diseñado para brindar seguridad integral durante el ciclo de vida de las claves y brindar visibilidad completa, lo que garantiza que las organizaciones puedan administrar las claves con confianza y sin complejidad adicional. Así es como ayudamos:

1. Visibilidad centralizada y mapeo de propiedad

Mediante una combinación de detección con y sin agentes, SSH Secure localiza todas las claves SSH en servidores y equipos de usuario. Todas las claves se almacenan en un único inventario con detalles de propiedad y uso, lo que elimina las claves huérfanas, reduce la proliferación de claves y garantiza la total trazabilidad en todo el entorno.

2. Control de acceso seguro y aplicación de claves vinculadas a la sesión

El control de acceso granular basado en roles (RBAC) garantiza que los usuarios solo reciban el nivel mínimo de acceso necesario. Para operaciones sensibles o temporales, SSH Secure emite claves efímeras vinculadas a la sesión que caducan automáticamente. En conjunto, estos controles refuerzan el principio de mínimo privilegio y minimizan las consecuencias de una posible filtración de credenciales.

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

SSH Secure automatiza el ciclo de vida completo de las claves, incluyendo la generación segura, la rotación basada en políticas, la expiración programada y la revocación. La gestión del ciclo de vida elimina las claves débiles o obsoletas, reduce la intervención humana y garantiza el cumplimiento continuo de las mejores prácticas del sector.

4. Protección integrada HSM

Todas las claves privadas están protegidas dentro de HSM, lo que garantiza la no exportabilidad y la resistencia a la manipulación. Las claves se generan mediante algoritmos criptográficos robustos como RSA-4096, ECDSAy Ed25519, que brindan protección sólida y resiliencia contra ataques de fuerza bruta y eficiencia.

5. Control basado en políticas para operaciones clave

Todas las operaciones clave, como la generación, los flujos de aprobación, la rotación y la revocación, se rigen por controles basados ​​en políticas. Esto garantiza la coherencia en todo el entorno, reduce los errores manuales y mantiene los estándares de seguridad de la organización. Las políticas pueden adaptarse a los requisitos normativos o personalizarse para respaldar los modelos de gobernanza interna.

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

SSH Secure proporciona monitorización en tiempo real de las actividades clave con registro detallado de eventos y detección de anomalías integrada. Los registros se pueden integrar con Splunk o paneles de Loki-Grafana para visualización, correlación y alertas avanzadas. Las capacidades de auditoría flexibles incluyen Registros descargables e informes detalladosEsto proporciona a los equipos de seguridad información clara sobre el uso de las claves y la situación general. La auditoría centralizada con alertas basadas en políticas permite una gestión de seguridad proactiva, una detección rápida de anomalías y una respuesta más ágil ante incidentes.

Conclusión

Las claves SSH estáticas han sido un elemento fundamental de la infraestructura empresarial durante décadas. También se encuentran entre las credenciales menos gestionadas sistemáticamente en los programas de seguridad modernos, acumulándose en toda la infraestructura, persistiendo indefinidamente y proporcionando acceso privilegiado mucho después de que los usuarios y sistemas para los que fueron creadas hayan desaparecido.

Los datos sobre claves de acceso raíz huérfanas, la investigación que demuestra que entre el 60 y el 90 % de las organizaciones carecen de un inventario completo de claves SSH, y los hallazgos del Instituto Ponemon sobre el coste de las filtraciones de acceso privilegiado documentan las consecuencias de un diseño de credenciales que nunca se concibió para la escala empresarial.

Efímero Las claves SSH resuelven directamente el problema estructural. El acceso se genera bajo demanda, se vincula a una identidad verificada, se autoriza según la política vigente y se invalida automáticamente al finalizar la sesión. La baja de usuario se convierte en un evento de política. El registro de auditoría es completo y se atribuye a la identidad, en lugar de limitarse a direcciones IP y huellas digitales de claves.

Para obtener más información sobre cómo SSH Secure aborda la proliferación de claves SSH y admite la emisión de claves SSH efímeras para el acceso privilegiado, o para analizar su entorno actual, Contacte con Consultoría de Cifrado.