SSH: gestión de claves y mejores prácticas

Secure Shell (SSH) es un protocolo de red que utiliza criptografía de clave pública para autenticar usuarios y cifrar los datos que fluyen hacia y desde sistemas remotos. SSH es el mecanismo principal para la administración remota de servidores, las transferencias de archivos entre sistemas y el acceso automatizado en pipelines de CI/CD. Dado que las claves SSH no tienen fecha de caducidad, ni Autoridad de Certificación, ni mecanismo de revocación, se acumulan silenciosamente en los archivos authorized_keys en toda la infraestructura, creando rutas de acceso persistentes que rara vez se revisan. La acción recomendada es: ejecutar un análisis de detección para inventariar todas las claves SSH en su entorno, implementar una política de rotación de claves con una antigüedad máxima de uno o dos años, deshabilitar la autenticación por contraseña en todos los servidores SSH, aplicar controles de acceso basados ​​en roles para la administración de claves y eliminar las claves codificadas directamente en el código de la aplicación.

Respuesta rápida: ¿Qué es la gestión de claves SSH y por qué es importante?

La gestión de claves SSH es el proceso de descubrir, inventariar, controlar, rotar y auditar pares de claves SSH en toda la infraestructura de una organización. Es importante porque las claves SSH son credenciales de autenticación potentes sin un mecanismo de caducidad o revocación integrado: una entrada en authorized_keys otorga acceso a cualquier persona que posea la clave privada correspondiente, de forma indefinida, a menos que la clave se rote o elimine explícitamente. Las grandes organizaciones acumulan cientos de miles de entradas en authorized_keys, muchas de ellas asociadas a exempleados, contratistas o cuentas de servicio que deberían haberse revocado años atrás. Una gestión deficiente de las claves SSH crea puertas traseras persistentes, permite el movimiento lateral entre servidores e incumple los requisitos de cumplimiento de PCI DSS, NIST SP 800-53 y HIPAA.

¿Qué es SSH y cómo funciona?

SSH (Secure Shell), definido en los RFC 4251-4254, es un protocolo de red criptográfico para el acceso remoto seguro, la transferencia de archivos y la creación de túneles. Funciona según el principio de criptografía de clave pública, utilizando pares de claves donde la clave pública se encuentra en los servidores en el archivo authorized_keys y la clave privada la posee el usuario o sistema que solicita el acceso. Cuando un cliente SSH se conecta a un servidor, este le pide al cliente que demuestre que posee la clave privada correspondiente a una clave pública autorizada, sin que la clave privada se transmita jamás a través de la red.

Entre los casos de uso típicos de SSH se incluyen el inicio de sesión remoto en servidores y dispositivos de red, las transferencias de archivos entre sistemas (SCP, SFTP), el acceso automatizado a la canalización de CI/CD para servidores de compilación e implementación, el reenvío de puertos y la creación de túneles, y el acceso programático a la API donde se utiliza SSH como protocolo de transporte.

Claves SSH frente a certificados X.509: Diferencias clave

Propiedad	Llaves SSH	Certificados X.509 (TLS)
Autoridad gobernante	Ninguna; las claves se gestionan de forma autónoma dentro de la organización.	La Autoridad de Certificación (CA) emite y firma certificados; el Foro CA/Browser rige las CA públicas.
Caducidad incorporada	Sin fecha de caducidad; las entradas de authorized_keys persisten indefinidamente a menos que se eliminen manualmente.	Los certificados tienen fechas de validez NotBefore y NotAfter impuestas por los clientes.
Mecanismo de revocación	No existe un equivalente a CRL u OCSP; la revocación requiere eliminar la clave pública de authorized_keys en cada servidor.	La CRL (Lista de Revocación de Certificados) y el OCSP (Protocolo de Estado de Certificados en Línea) permiten la revocación.
Validación de identidad	Sin validación de CA; el servidor confía en cualquier clave en authorized_keys independientemente de quién la haya generado.	La CA valida la identidad del titular del certificado antes de su emisión (para las CA públicas: validación de dominio o validación de organización).
Capacidad de acceso remoto	Permite el inicio de sesión remoto y la ejecución de comandos en servidores.	Proporciona autenticación para conexiones de red, pero no habilita el acceso remoto a la consola por sí solo.
Desafío de inventario	No existe un registro central; las claves deben descubrirse escaneando servidores y sistemas.	Los certificados se pueden descubrir a través de los registros de Transparencia de Certificados; las herramientas PKI realizan un seguimiento de los certificados emitidos.

Riesgos de las claves SSH no gestionadas

La ausencia de caducidad y revocación integradas hace que la gestión de claves SSH sea un desafío distinto al de la gestión de certificados. Riesgos específicos que generan las claves SSH no gestionadas:

• Puertas traseras persistentes de exempleados y contratistas: Cuando un desarrollador, administrador de sistemas o contratista abandona la empresa, su clave pública SSH permanece en los archivos authorized_keys de todos los servidores a los que tenía acceso, a menos que se elimine explícitamente. Un exempleado que aún conserva su clave privada mantiene el acceso a esos servidores de forma indefinida.
• Elemento clave que permite el movimiento lateral: En grandes organizaciones, una única cuenta de servicio o sistema de compilación puede tener su clave pública en authorized_keys en cientos de servidores. Un atacante que comprometa un sistema con una clave privada SSH autorizada puede usar esa clave para autenticarse en todos los demás servidores que confíen en la clave pública correspondiente, lo que permite un rápido movimiento lateral por todo el entorno.
• Claves obsoletas con algoritmos débiles: Las claves generadas hace años pueden usar RSA-1024 o DSA (ambos algoritmos obsoletos) porque la política y las herramientas de la época no exigían algoritmos más robustos. Sin un proceso de detección e inventario, estas claves débiles permanecen indefinidamente en authorized_keys.
• Claves codificadas directamente en las aplicaciones: Las claves SSH integradas en el código de la aplicación, las imágenes de Docker o los archivos de configuración son difíciles de rotar, pueden quedar expuestas a través de los repositorios de código fuente y persisten en el historial de versiones incluso después de su eliminación del código base actual.
• A menudo se omite la rotación de teclas: Sin una gestión automatizada, la rotación de claves requiere actualizar manualmente authorized_keys en cada servidor que confía en la clave. En entornos con cientos de servidores, esto resulta engorroso desde el punto de vista operativo y, con frecuencia, se pospone indefinidamente.

Selección de algoritmo y tipo de clave para SSH

Tipo de llave	Algoritmo	Fuerza de seguridad	Recomendación	Notas
Ed25519	DSA de curva de Edwards (EdDSA)	128 bits	Preferible para la generación de nuevas claves SSH	Rápido, compacto (clave pública de 32 bytes), resistente a ataques de canal lateral basados ​​en la temporización, compatible con OpenSSH 6.5+ (lanzado en 2014).
ECDSA P-256	Curva elíptica DSA	128 bits	Aceptable; utilice Ed25519 en su lugar si está disponible.	Mayor compatibilidad con sistemas más antiguos; menos resistente a ataques de temporización que Ed25519.
RSA-3072	RSA	128 bits	Aceptable cuando no se admite Ed25519/ECDSA.	Tamaño de clave mucho mayor (384 bytes frente a 32 bytes para Ed25519); operaciones más lentas; compatible con la más amplia gama de sistemas heredados.
RSA-2048	RSA	112 bits	Mínimo; planifique la migración a tipos de claves más robustos.	Se propone su descontinuación después de 2030 según NIST IR 8547; utilice RSA-3072 o Ed25519 para nuevas claves.
RSA-1024	RSA	80 bits (roto)	No utilice	El NIST lo desautorizó para nuevas claves; es computacionalmente vulnerable.
DSA	DSA (original)	80 bits (obsoleto)	No utilice	Tamaño de clave fijo de 1024 bits; declarado obsoleto por NIST; eliminado de OpenSSH 7.0+ por defecto.

Mejores prácticas para la gestión de claves SSH

1. Obtenga visibilidad completa a través del descubrimiento: El primer paso en la gestión de claves SSH es saber qué claves tienes. Realiza escaneos de detección periódicos en todos los servidores y dispositivos de red para localizar e inventariar todas las entradas de authorized_keys y todas las claves privadas SSH de la red. Asocia cada clave pública autorizada con la cuenta de usuario o sistema a la que pertenece, los servidores a los que otorga acceso, la fecha de generación y el algoritmo y tamaño de clave que utiliza. Sin este inventario, ningún otro control de gobernanza resulta efectivo.
2. Implementar una política de antigüedad máxima y rotación de claves: Defina una política que requiera la rotación de las claves SSH según un calendario predefinido. Para las claves de usuario interactivas, es común una antigüedad máxima de uno a dos años. Para las cuentas de servicio y los sistemas automatizados, se recomiendan intervalos de rotación más cortos para accesos de mayor riesgo. La rotación requiere generar un nuevo par de claves, distribuir la nueva clave pública a todos los servidores autorizados, verificar el acceso y eliminar la clave pública anterior de todos los archivos authorized_keys. Automatice este proceso en entornos de gran tamaño.
3. Deshabilitar la autenticación por contraseña en servidores SSH: Configure todos los servidores SSH con PasswordAuthentication no y ChallengeResponseAuthentication no en sshd_config. Exija exclusivamente autenticación basada en claves. La autenticación por contraseña es vulnerable a ataques de fuerza bruta y phishing; la autenticación por clave SSH es inmune a ambos si se gestiona correctamente.
4. Aplicar registros de auditoría y políticas: Registre todos los eventos de autenticación SSH, incluyendo la clave utilizada y la dirección IP de origen, en un SIEM centralizado. Estos registros son esenciales para detectar accesos no autorizados (por ejemplo, el uso de una clave antigua desde una ubicación inesperada tras la salida de un exempleado) y para demostrar el cumplimiento de las normas PCI DSS, NIST SP 800-53 y los requisitos de auditoría de HIPAA. Adapte la configuración de registro a la política de uso de claves de su organización.
5. Implementar permisos basados ​​en roles para la gestión de claves: Restrinja quién puede agregar, modificar o eliminar entradas en los archivos authorized_keys. En entornos donde los administradores pueden agregar entradas a authorized_keys arbitrariamente y sin supervisión, se acumulan concesiones de acceso no autorizadas o no documentadas. Utilice servicios de directorio o una plataforma centralizada de gestión de claves SSH para garantizar que todas las concesiones de claves sigan un flujo de trabajo de aprobación y se registren en el inventario.
6. Elimine las claves codificadas directamente en el código de la aplicación: Las claves privadas SSH integradas en el código de la aplicación, las imágenes de contenedor o los archivos de configuración son peligrosas: son difíciles de rotar, pueden quedar expuestas a través de los repositorios de código fuente (incluido el historial del repositorio tras su eliminación) y, a menudo, tienen un amplio acceso. Reemplace las claves codificadas con credenciales aprovisionadas dinámicamente y obtenidas de un sistema de gestión de secretos en tiempo de ejecución.
7. Utilice claves privadas protegidas con contraseña para el uso interactivo: Las claves privadas SSH utilizadas para el inicio de sesión interactivo deben protegerse con una contraseña segura. Esta contraseña cifra el archivo de clave privada, impidiendo que un atacante que lo obtenga pueda utilizarlo sin conocerla. En sistemas automatizados, la clave privada debe almacenarse en un sistema de gestión de secretos con controles de acceso, en lugar de en texto plano en el sistema de archivos.

Ejemplo de implementación: Gobernanza de claves SSH empresariales

Una organización con 500 servidores Linux y un entorno DevOps que utiliza SSH para el acceso a la canalización de CI/CD implementa el siguiente programa de gobernanza de claves SSH:

1. Descubrimiento inicial: Ejecuta un escaneo de detección de claves SSH en los 500 servidores. El escaneo enumera todas las entradas en /root/.ssh/authorized_keys y /home/*/.ssh/authorized_keys, catalogando la huella digital, el algoritmo, el tamaño de la clave y las cuentas y servidores en los que aparece cada clave pública. El escaneo inicial revela 47 000 entradas en authorized_keys, de las cuales 12 000 no tienen una cuenta de usuario correspondiente en el Directorio Activo actual, lo que indica que se trata de claves de antiguos empleados o contratistas que nunca fueron revocadas.
2. Revocación de emergencia de claves huérfanas: Las 12 000 entradas de authorized_keys huérfanas se eliminan de todos los servidores afectados. Las 35 000 entradas restantes se asignan a las cuentas de usuario o de servicio actuales y se añaden al inventario de claves con estado de revisión pendiente.
3. Corrección del algoritmo: El inventario identifica 3,200 claves RSA-1024 y 800 claves DSA que deben reemplazarse. Se generan nuevas claves Ed25519 para los usuarios y cuentas de servicio afectados, se distribuyen a todos los servidores pertinentes y se eliminan las claves antiguas. Las claves RSA-2048 se marcan para su rotación a RSA-3072 o Ed25519 en su próxima rotación programada.
4. Implementación del cronograma de rotación: Se establece una política que exige la rotación anual de todas las claves SSH para los usuarios interactivos y cada seis meses para las cuentas de servicio con acceso a sistemas de producción. Una plataforma de gestión de claves SSH automatiza la rotación: genera nuevas claves, actualiza la lista de claves autorizadas en todos los servidores afectados y elimina las claves antiguas tras confirmar la autenticación correcta con la nueva clave.
5. Sustitución de credenciales de la canalización CI/CD: Las claves privadas SSH codificadas en los archivos de configuración de la canalización de CI/CD se identifican y reemplazan con credenciales temporales aprovisionadas dinámicamente y obtenidas de un sistema de gestión de secretos durante la compilación. Las claves antiguas codificadas se revocan y se eliminan de authorized_keys.
6. Registro de auditoría continuo: Los eventos de autenticación SSH se reenvían al SIEM. Se configuran alertas para eventos de autenticación que utilizan claves con una antigüedad superior a la máxima permitida por la política, autenticación desde direcciones IP de origen inesperadas que utilizan claves de cuenta de servicio y cualquier nueva entrada de authorized_keys añadida fuera del flujo de trabajo aprobado.

Limitaciones de los controles de gestión de claves SSH

• No existe ninguna autoridad central autóctona: SSH carece de un modelo de CA, por lo que no existe una única fuente de información fidedigna sobre las claves existentes. Cada archivo authorized_keys en cada servidor constituye un almacén de confianza independiente. Mantener un inventario coherente requiere un escaneo de detección activa en lugar de consultar un registro central.
• La gestión manual de authorized_keys a gran escala resulta poco práctica: Las organizaciones con más de unas pocas docenas de servidores no pueden gestionar manualmente la administración de claves SSH. Las plataformas automatizadas de administración de claves SSH son un requisito práctico, no una optimización, para los entornos empresariales.
• Autoridad de certificación SSH (SSH CA) como modelo alternativo: OpenSSH admite una alternativa a authorized_keys mediante autoridades de certificación SSH: la CA SSH firma la clave pública de un usuario para crear un certificado SSH con caducidad integrada y revocación opcional. Este modelo proporciona las funcionalidades de caducidad y revocación de las que carecen las claves SSH convencionales, pero requiere actualizar todos los servidores SSH para que confíen en la CA SSH e implementar el flujo de trabajo de emisión de certificados. Para las organizaciones dispuestas a invertir en la infraestructura, las CA SSH resuelven la mayoría de los problemas de gobernanza de las claves SSH convencionales.
• Vulnerabilidad de la computación cuántica: Las claves RSA SSH son vulnerables a la computación cuántica. Las claves Ed25519 y ECDSA también lo son, pero tienen un período de seguridad proyectado más prolongado. El NIST está trabajando en algoritmos postcuánticos para criptografía asimétrica; las organizaciones con infraestructura SSH que deban mantener la seguridad hasta la década de 2030 deberían planificar la migración de algoritmos a medida que maduren los estándares de PQC.

Cómo puede ayudar la consultoría de cifrado

• SSH seguro: nuestro mapa de SSH seguro Esta solución proporciona una gestión automatizada del ciclo de vida de las claves SSH, que incluye escaneo de detección, inventario centralizado, automatización de la rotación, aplicación de políticas y registro de auditoría. Elimina la carga manual de la gobernanza de claves SSH a gran escala y garantiza el cumplimiento de los requisitos de PCI DSS, NIST SP 800-53 y HIPAA para la gestión de credenciales de autenticación.
• Servicios de asesoramiento sobre cifrado: nuestro mapa de Servicios de asesoramiento sobre cifrado Evaluamos su infraestructura actual de claves SSH, identificamos claves huérfanas, algoritmos débiles, credenciales codificadas y deficiencias en las políticas, y proporcionamos una hoja de ruta de remediación alineada con los requisitos de cumplimiento.
• CBOM Seguro: CBOM seguro Descubre todos los activos criptográficos de su entorno, incluidas las claves SSH, y proporciona el inventario necesario para identificar algoritmos débiles (RSA-1024, DSA) y planificar la migración a tipos de claves más seguros.

Conclusión

Las claves SSH son credenciales de autenticación potentes que otorgan acceso directo a los servidores. Al carecer de caducidad, revocación o una autoridad central, se acumulan silenciosamente en los archivos authorized_keys, creando rutas de acceso persistentes mucho después de que haya finalizado su uso previsto. Las consecuencias de una mala gestión de las claves SSH van desde infracciones de cumplimiento normativo hasta importantes filtraciones de datos facilitadas por el movimiento lateral a través de una red de servidores que confían en la misma clave privada comprometida.

El programa de gobernanza es sencillo: detectar, inventariar, corregir algoritmos débiles, garantizar la rotación, deshabilitar la autenticación por contraseña, restringir quién puede administrar las claves y auditar el acceso de forma continua. La automatización es indispensable a escala empresarial: el esfuerzo manual de mantener las claves autorizadas en cientos de servidores sin herramientas prácticamente garantiza el fracaso de la gobernanza. Si desea evaluar la seguridad de sus claves SSH o implementar la gestión automatizada del ciclo de vida, póngase en contacto con Encryption Consulting . Para obtener más información, consulte nuestra guía sobre gestión de claves en criptografía .

Preguntas frecuentes

¿Qué es SSH y en qué se diferencia de los certificados TLS?

SSH utiliza criptografía de clave pública para autenticar usuarios y cifrar las sesiones de acceso remoto. Las claves SSH son autogobernadas, sin autoridad de certificación (CA), sin fecha de caducidad predefinida ni mecanismo de revocación. Los certificados TLS son emitidos por autoridades de certificación, tienen fechas de validez y pueden revocarse mediante CRL u OCSP. SSH permite exclusivamente el acceso remoto a la consola y la ejecución de comandos, funcionalidades que los certificados TLS por sí solos no ofrecen.

¿Qué es la proliferación de claves SSH y por qué supone un riesgo para la seguridad?

La proliferación de claves SSH consiste en la acumulación incontrolada de pares de claves SSH en la infraestructura sin gestión de inventario ni de su ciclo de vida. Cada entrada en authorized_keys representa una ruta de acceso persistente que permanece activa hasta que se elimina explícitamente. Las claves de exempleados y contratistas que nunca se revocaron, así como las claves de cuentas de servicio distribuidas en cientos de servidores, crean puertas traseras que los atacantes pueden explotar indefinidamente.

¿Qué algoritmos se deben utilizar para las claves SSH?

El algoritmo preferido actualmente es Ed25519: ofrece seguridad de 128 bits, es rápido, compacto y resistente a ataques de canal lateral por temporización. ECDSA P-256 también es aceptable. RSA-3072 es aceptable para compatibilidad con versiones anteriores; RSA-2048 es el mínimo. No se deben usar RSA-1024 ni DSA. Se recomienda planificar la migración a algoritmos PQC a medida que maduren los estándares NIST para los tipos de claves SSH.

¿Cómo se deben rotar las claves SSH?

Genera un nuevo par de claves, agrega la nueva clave pública al archivo authorized_keys en todos los servidores de destino, verifica el acceso y, a continuación, elimina la clave pública antigua de todos los archivos authorized_keys y destruye la clave privada antigua. Define una política de antigüedad máxima de claves (de uno a dos años para claves interactivas; menor para cuentas de servicio) y automatiza la rotación en entornos con más de unas pocas docenas de servidores.

¿Qué marcos de cumplimiento normativo requieren controles de gestión de claves SSH?

Los requisitos 8.2 y 8.6 de PCI DSS abordan la autenticación de credenciales y la gestión de cuentas no interactivas, incluyendo las claves SSH. NIST SP 800-53 AC-2 e IA-5 exigen inventario, rotación y revocación de credenciales de autenticación. Las salvaguardas técnicas de HIPAA (164.312(d)) exigen controles de autenticación de entidades para sistemas que manejan información médica electrónica protegida (ePHI). Los anexos A.9.3 y A.9.4 de ISO 27001 exigen controles sobre mecanismos de autenticación criptográfica.

¿Cuál es la diferencia entre las claves SSH y la autenticación por contraseña?

La autenticación mediante clave SSH utiliza un mecanismo criptográfico de desafío-respuesta; no se transmite ningún secreto a través de la red. La autenticación mediante contraseña transmite una contraseña (dentro de la sesión SSH cifrada). Las claves SSH son inmunes a los ataques de fuerza bruta y phishing, utilizan secretos de 256 a 4096 bits (en comparación con las contraseñas comunes y fáciles de recordar) y deberían ser el método de autenticación exclusivo en los servidores SSH (PasswordAuthentication no en sshd_config).