Ir al contenido

¡Se acercan los certificados de 47 días! ¿Estás preparado?

Actúa ahora →

Comparación de claves SSH: RSA, DSA, ECDSA o EdDSA

Comparación de claves SSH

La selección del algoritmo de clave SSH (Secure Shell) determina la base criptográfica de cada autenticación de acceso remoto en su infraestructura. RSA, DSA, ECDSA y EdDSA (Ed25519) tienen propiedades de seguridad, tamaños de clave, características de rendimiento y estado de cumplimiento fundamentalmente diferentes. DSA está obsoleto (deshabilitado en OpenSSH 7.0+; obsoleto según NIST en FIPS 186-5). Ed25519 es el estándar moderno: firmas deterministas, implementación de tiempo constante, seguridad equivalente a 128 bits y los tamaños de clave más pequeños de cualquier algoritmo SSH convencional. En entornos regidos por normativas de cumplimiento (PCI DSS, NIST SP 800-53, FedRAMP), la selección del algoritmo es una decisión de gobernanza con consecuencias de auditoría. La acción recomendada: migrar a Ed25519 para todas las nuevas implementaciones de claves SSH; usar RSA-4096 solo para sistemas heredados que no pueden admitir Ed25519; planificar la migración desde DSA como un elemento de remediación prioritario.

Respuesta rápida: ¿Qué algoritmo de clave SSH debería utilizar?

Ed25519 para todas las nuevas implementaciones de SSH. Proporciona seguridad equivalente a aproximadamente 128 bits, firmas deterministas (eliminando la clase de fallo de nonce), operaciones de tiempo constante y los tamaños de clave y firma más pequeños de cualquier algoritmo SSH principal. OpenSSH moderno usa Ed25519 por defecto. RSA-4096 con firmas SHA-2 como alternativa para sistemas heredados que no admiten Ed25519. Evite DSA por completo: obsoleto por NIST, deshabilitado por defecto en OpenSSH 7.0+, limitado a seguridad equivalente a 80 bits y vulnerable a la recuperación de claves mediante reutilización de nonce. ECDSA es aceptable, pero se prefiere Ed25519. Para la gestión del ciclo de vida de las claves SSH a gran escala, consulte SSH Secure y nuestra publicación sobre la política de rotación de claves SSH.

¿Qué son las claves SSH?

Las claves SSH son pares de claves criptográficas asimétricas que se utilizan para autenticar usuarios o servidores a través de SSH sin enviar contraseñas por la red. Cada par consta de una clave privada que permanece en el dispositivo del cliente y una clave pública que se agrega al archivo authorized_keys del servidor para la cuenta de usuario de destino. Al conectarse, el servidor verifica que el cliente posea la clave privada correspondiente a la clave pública autorizada mediante un intercambio de desafío-respuesta; la clave privada nunca se transmite.

La seguridad se basa en la criptografía asimétrica (de clave pública) : las claves privada y pública están vinculadas matemáticamente, de modo que un mensaje firmado con la clave privada solo puede verificarse con la clave pública correspondiente, pero la clave privada no puede derivarse de la clave pública en un plazo de tiempo razonable. El algoritmo específico (RSA, DSA, ECDSA, EdDSA) define el problema matemático sobre el que se fundamenta esta asimetría y determina cómo se generan las firmas, cómo se verifican y el coste computacional de cada operación.

El protocolo de autenticación SSH funciona de la siguiente manera:

  1. El cliente inicia una conexión SSH con el servidor y presenta su clave pública.
  2. El servidor comprueba si esa clave pública figura en el archivo authorized_keys de la cuenta de usuario de destino.
  3. Si se detecta, el servidor genera un desafío aleatorio y lo cifra utilizando la clave pública del cliente.
  4. El servidor envía el desafío al cliente.
  5. El cliente descifra el desafío utilizando su clave privada y envía la respuesta.
  6. El servidor verifica la respuesta, confirmando que el cliente posee la clave privada sin que esta sea transmitida.

Las claves SSH se utilizan no solo para inicios de sesión interactivos, sino también para transferencias de archivos (SCP, SFTP ), reenvío de puertos, tunelización, operaciones Git y comunicación automatizada entre máquinas en pipelines de CI/CD.

Los cuatro algoritmos de clave SSH

RSA es el valor predeterminado histórico; DSA es obsoleto; ECDSA es una alternativa de curva elíptica; EdDSA (Ed25519) es el valor predeterminado moderno para nuevas configuraciones. OpenSSH admite RSA, ECDSA y Ed25519; las versiones modernas utilizan Ed25519 por defecto cuando no se especifica ningún tipo.

RSA (Rivest-Shamir-Adleman)

RSA se basa en la dificultad matemática de factorizar números enteros muy grandes en números primos. La seguridad depende en gran medida de la longitud de la clave: las claves de 1024 bits ya no son seguras; RSA-2048 es el mínimo aceptable; RSA-3072 o RSA-4096 son apropiadas para nuevas implementaciones. OpenSSH admite RSA y permite su generación con la opción -t rsa.

Ventajas de RSA: La principal ventaja de RSA es su compatibilidad. Funciona con servidores heredados, dispositivos de red, herramientas de automatización y productos empresariales que podrían no ser compatibles con algoritmos más recientes. En infraestructuras de generaciones mixtas, RSA ofrece la compatibilidad más eficiente. Además, RSA cuenta con décadas de experiencia operativa: los administradores se sienten cómodos auditando, rotando y solucionando problemas de acceso SSH basado en RSA.

Limitaciones de RSA: Las claves RSA son significativamente más grandes que las claves de curva elíptica con niveles de seguridad equivalentes: requieren más almacenamiento, mayor ancho de banda y son más lentas. Muchos debates sobre la obsolescencia de RSA se refieren específicamente al antiguo esquema de firma SHA-1 de ssh-rsa, en lugar de a RSA en sí; el RSA moderno con firmas SHA-2 (rsa-sha2-256, rsa-sha2-512) sigue siendo aceptable a partir de 3072 bits.

Caso de uso de RSA: un servidor bastión heredado o un dispositivo de proveedor que solo acepta claves RSA. En estos entornos, RSA-4096 con firmas SHA-2 puede ser la única opción práctica hasta que el hardware o el firmware se actualicen para admitir Ed25519.

DSA (Algoritmo de firma digital)

Históricamente, DSA se utilizaba en SSH, pero hace tiempo que se dejó de usar y se deshabilitó en las implementaciones modernas. No utilice DSA en ninguna implementación nueva de SSH y considere las claves DSA existentes como una prioridad para la migración.

¿Por qué se ha descontinuado DSA? Tres razones concretas y bien documentadas:

  • El protocolo SSH limita estrictamente las claves DSA a 1024 bits, lo que proporciona una seguridad equivalente a aproximadamente 80 bits, muy por debajo del mínimo de 112 bits que exige el NIST para los nuevos trabajos criptográficos desde 2014.
  • Las firmas DSA requieren un número aleatorio secreto por firma. Si este número se repite o es predecible, la clave privada puede recuperarse matemáticamente a partir de dos firmas. Incidentes reales (como el jailbreak de PlayStation 3 o el compromiso de monederos de Bitcoin) han demostrado repetidamente este tipo de fallo.
  • El NIST desaconsejó formalmente el uso de DSA para la generación de firmas en la norma FIPS 186-5 (2023), lo que convierte a DSA en un riesgo de cumplimiento en cualquier entorno regulado.

OpenSSH 7.0 y versiones posteriores desactivan DSA de forma predeterminada por estos motivos. En cualquier sistema actual, las claves DSA no funcionarán sin volver a habilitar explícitamente un algoritmo obsoleto, lo que indica que es necesario migrar en lugar de volver a habilitarlo.

Escenario DSA: entornos heredados con un servidor de larga duración que nunca se ha modernizado. La respuesta correcta es planificar la migración, no seguir utilizándolo.

ECDSA (Algoritmo de firma digital de curva elíptica)

ECDSA utiliza criptografía de curva elíptica , lo que proporciona una seguridad robusta con claves mucho más pequeñas que RSA. SSH admite tamaños de curva de 256, 384 y 521 bits (P-256, P-384, P-521). ssh-keygen aplica estos tamaños específicos.

Ventajas de ECDSA: buen rendimiento y tamaños de clave reducidos en comparación con RSA. Útil en entornos con recursos limitados donde el tamaño de la clave y la sobrecarga de transmisión son importantes.

Limitaciones de ECDSA: ECDSA comparte la dependencia del valor aleatorio (nonce) con DSA: las firmas requieren un valor aleatorio por firma, y ​​un generador de números aleatorios deficiente puede permitir la recuperación de la clave privada. Generalmente se prefiere Ed25519 porque su esquema de firma determinista elimina por completo este tipo de riesgo. Las curvas P de ECDSA del NIST también han generado dudas sobre su posible manipulación, aunque no se ha demostrado ninguna vulnerabilidad explotable.

Caso de uso de ECDSA: un entorno de producción con recursos limitados donde se requiere criptografía de curva elíptica y la pila de software ya es compatible con ECDSA. Para nuevas implementaciones sin esta limitación, Ed25519 es la mejor opción predeterminada.

Servicios de implementación para soluciones de gestión de claves

Brindamos servicios de implementación personalizados de soluciones de protección de datos que se alinean con las necesidades de su organización.

EdDSA / Ed25519

EdDSA es una familia de esquemas de firma digital modernos; en la práctica de SSH, casi siempre se hace referencia a Ed25519 (basado en Curve25519, que proporciona una seguridad equivalente a aproximadamente 128 bits). OpenSSH añadió compatibilidad con Ed25519 en la versión 6.5 y las versiones actuales utilizan Ed25519 por defecto cuando no se especifica ningún algoritmo.

Ventajas de Ed25519: rápido, compacto y seguro por defecto. Diferencias clave con DSA y ECDSA: las firmas se generan de forma determinista mediante un hash de la clave privada y el mensaje (no un valor aleatorio), eliminando por completo la posibilidad de fallos en el valor aleatorio. Las operaciones se ejecutan en tiempo constante para resistir ataques de canal lateral. El tamaño de las claves es el más pequeño de cualquier algoritmo SSH convencional. Curve25519 se diseñó priorizando la seguridad de la implementación.

Limitaciones de Ed25519: compatibilidad con servidores, dispositivos o servicios gestionados SSH muy antiguos. Es posible que los sistemas muy antiguos no sean compatibles con Ed25519, por lo que se requiere RSA como alternativa. Estas brechas de compatibilidad son cada vez menos frecuentes a medida que se actualiza la infraestructura.

Caso de uso de Ed25519: la opción predeterminada para todas las implementaciones modernas de SSH. Un ingeniero de software que genera una clave SSH personal para GitHub, GitLab o un servidor bastión de producción; un sistema de automatización que requiere acceso seguro no interactivo; cualquier nueva implementación de SSH donde la compatibilidad con sistemas muy antiguos no sea una limitación.

Comparación lado a lado

AlgoritmoSeguridadRendimientoTamaño claveCompatibilidadEstadoRecomendado para
RSA-4096Firmas SHA-2 sólidasGenerador de claves y firma lentosAnchaExcelente (todos los sistemas)Aceptado; usar SHA-2Sistemas heredados y máxima compatibilidad
RSA-2048Mínimo aceptable (~112 bits)Más rápido que 4096AnchaExcelenteMínimo; migrar a 3072+Restricciones heredadas únicamente
DSADébil (1024 bits, seguridad de ~80 bits)Lento; dependiente de nonceModeradoDeshabilitado en OpenSSH 7.0+Obsoleto (FIPS 186-5, 2023)No utilizar; tratar como prioridad de migración
ECDSA P-256Fuerte; sensible a los pedofiliaRápidoPequeñaBuenos (sistemas modernos)AceptadosImplementaciones de ECDSA existentes o requisitos de curva elíptica
EdDSA / Ed25519Muy robusto (~128 bits; determinista)Muy rápido; tiempo constanteMuy pequeñaFuertes en sistemas modernosRecomendado (opción predeterminada moderna)Todas las nuevas implementaciones de SSH

Guía de selección de algoritmos

Para sistemas nuevos: Ed25519. El mejor equilibrio entre seguridad, rendimiento y simplicidad; predeterminado en OpenSSH moderno; sin riesgo de fallo de nonce; implementación de tiempo constante.

Para garantizar la compatibilidad con versiones anteriores: utilice RSA-4096 con firmas SHA-2 (rsa-sha2-256 o rsa-sha2-512) al conectarse a servidores, dispositivos o software antiguos que no admiten Ed25519. Confirme que está utilizando un esquema de firma moderno, no la variante obsoleta ssh-rsa basada en sha-1.

Para casos especiales: ECDSA con P-256 o superior cuando se requiera criptografía de curva elíptica y Ed25519 no esté disponible. Asegúrese de que el generador de números aleatorios (RNG) utilizado durante la firma sea criptográficamente seguro.

DSA: no utilizar. Tratar las claves DSA existentes como un elemento de migración prioritario, independientemente del entorno.

Estrategia práctica de migración: ejecute tanto RSA como Ed25519 durante la transición. Mantenga RSA solo para los sistemas que aún no pueden admitir Ed25519 y elimínelo gradualmente a medida que esos sistemas se actualicen:

  1. Genere una nueva clave Ed25519 como identidad SSH principal.
  2. Utilice una clave RSA-4096 únicamente para los sistemas que la requieran.
  3. Agregue ambas claves públicas a authorized_keys donde sea necesario.
  4. Supervise qué claves siguen en uso mediante los registros de acceso SSH y la comparación de huellas digitales de las claves.
  5. Elimine las claves RSA una vez que los sistemas heredados que las requieren se actualicen o se desactiven.

Política de gestión del ciclo de vida de las claves SSH y de acceso

La selección del algoritmo es solo la primera decisión en la gobernanza de claves SSH. El ciclo de vida de cada clave requiere una gestión activa:

  • Propiedad del ciclo de vida: Cada clave SSH debe tener un propietario documentado. Las claves sin propietario se acumulan indefinidamente en los archivos authorized_keys. Asigne la propiedad al generar la clave y realice un seguimiento en un inventario centralizado.
  • Disparadores de rotación: Con base en el tiempo (al menos anualmente); salida de un empleado o cambio de rol (inmediatamente); compromiso sospechado o confirmado (inmediatamente); obsolescencia de algoritmos (inmediatamente); reinstalación de la imagen del sistema.
  • Política de acceso: Aplicar el principio de mínimo privilegio; cada usuario debe tener un par de claves único; las claves SSH no deben compartirse entre usuarios; las claves de root requieren controles adicionales y flujos de trabajo de aprobación.
  • Evidencia de auditoría: Registre todos los eventos de acceso SSH con la huella digital de la clave, la marca de tiempo, la dirección IP de origen y el usuario de destino. Conserve estos registros para cumplir con los requisitos de conformidad (PCI DSS, NIST SP 800-53, ISO 27001).
  • Proceso de rotación: Generar un nuevo par de claves; distribuir la nueva clave pública a todos los servidores autorizados; verificar que la nueva clave se autentique correctamente; eliminar la clave pública antigua de los archivos authorized_keys de todos los servidores; actualizar el inventario.

Para la gestión del ciclo de vida de las claves SSH a escala empresarial, consulte SSH Secure y nuestra publicación sobre el diseño de una política de rotación de claves SSH.

Consideraciones post-cuánticas para claves SSH

Los cuatro algoritmos de clave SSH aquí analizados son vulnerables a una computadora cuántica suficientemente potente que ejecute el algoritmo de Shor, el cual puede romper tanto la factorización de enteros (RSA, DSA) como el logaritmo discreto de curva elíptica (ECDSA, EdDSA) en tiempo polinomial. Si bien aún no existen computadoras cuánticas relevantes para la criptografía, las organizaciones con requisitos de confidencialidad a largo plazo deberían comenzar a planificar la criptografía postcuántica.

Intercambio de claves post-cuántico (KEX) en SSH: OpenSSH 10.0 introdujo mlkem768x25519-sha256 como intercambio de claves predeterminado, combinando el clásico X25519 con ML-KEM-768 (CRYSTALS-Kyber estandarizado por NIST, FIPS 203 ). Esta construcción híbrida protege la confidencialidad de la sesión: la clave de sesión se deriva de ambos componentes, permaneciendo segura mientras cualquiera de los algoritmos sea válido. Esto aborda directamente los ataques de "cosecha ahora, descifrado después" dirigidos a sesiones SSH registradas. En versiones anteriores de OpenSSH, desde la 9.0 hasta la 9.9, está disponible sntrup761x25519-sha512, que debería preferirse al intercambio de claves clásico puro para tráfico de alta sensibilidad.

Claves de autenticación SSH post-cuánticas: aún en desarrollo inicial. Se espera que los algoritmos de firma post-cuántica aprobados por el NIST (ML-DSA / CRYSTALS-Dilithium, FIPS 204) se incorporen a OpenSSH para la autenticación en futuras versiones. Ed25519 sigue siendo la mejor opción práctica para la autenticación SSH en la actualidad; migre a las claves de autenticación post-cuánticas cuando estén estandarizadas en OpenSSH y el ecosistema en general esté listo.

Cómo puede ayudar la consultoría de cifrado

SSH Secure proporciona una gestión integral del ciclo de vida de las claves SSH con total visibilidad y control a escala empresarial:

  • Mapeo centralizado de visibilidad y propiedad: El descubrimiento, tanto con agente como sin él, localiza todas las claves SSH en servidores y máquinas de usuario; todas las claves se almacenan en un único inventario con detalles de propiedad y uso, lo que elimina las claves huérfanas y reduce la dispersión de claves.
  • Control de acceso seguro: El control de acceso basado en roles (RBAC) granular garantiza que los usuarios reciban el acceso mínimo necesario; las claves efímeras vinculadas a la sesión se utilizan para operaciones confidenciales que caducan automáticamente.
  • Orquestación automatizada del ciclo de vida de las claves: Generación automatizada mediante Ed25519, ECDSA y RSA-4096; rotación basada en políticas, caducidad programada y revocación; la gobernanza del ciclo de vida elimina las claves débiles y obsoletas.
  • Protección de clave privada integrada en HSM: Claves privadas protegidas dentro de módulos de seguridad de hardware (HSM); no exportables; a prueba de manipulaciones; aisladas de ataques de compromiso a nivel del sistema operativo y de extracción de datos de memoria.
  • Operaciones clave impulsadas por políticas: Toda la generación, aprobación, rotación y revocación se rigen por controles basados ​​en políticas; son consistentes en todo el entorno y se adaptan a los requisitos reglamentarios.
  • Supervisión continua, auditoría y preparación para el cumplimiento normativo: Monitorización en tiempo real con detección de anomalías; integración con Splunk y Loki-Grafana; registros de auditoría e informes de cumplimiento descargables.

Conclusión

La selección del algoritmo de clave SSH es una decisión de seguridad con implicaciones de cumplimiento. RSA ofrece compatibilidad con entornos heredados; DSA está obsoleto y deshabilitado en las implementaciones modernas de SSH y debe migrarse de inmediato; ECDSA es una opción válida de curva elíptica, pero requiere una gestión cuidadosa del generador de números aleatorios (RNG); Ed25519 es la recomendación clara para todas las nuevas implementaciones de SSH, ya que ofrece la mejor combinación de seguridad, rendimiento, simplicidad y eliminación de vulnerabilidades a nivel de implementación. Combine Ed25519 con OpenSSH 10.0+ para beneficiarse del intercambio de claves post-cuántico que ya protege la confidencialidad de la sesión. Más allá de la selección del algoritmo, la seguridad de la clave SSH depende de las prácticas de gestión del ciclo de vida que rigen cómo se poseen, rotan, revocan y auditan las claves. La elección del algoritmo y la gobernanza del ciclo de vida determinan conjuntamente la postura de seguridad real del acceso SSH en su entorno. Para obtener más información, consulte nuestras publicaciones sobre autenticación SSH sin contraseña , política de rotación de claves SSH y SSH Secure.

Preguntas frecuentes

¿Qué algoritmo de clave SSH debería usar en 2026?

Ed25519 para todas las nuevas implementaciones de SSH: seguridad equivalente a aproximadamente 128 bits, firmas deterministas (sin riesgo de fallo de nonce), operaciones de tiempo constante y los tamaños de clave más pequeños de cualquier algoritmo convencional. OpenSSH moderno utiliza Ed25519 por defecto. RSA-4096 con SHA-2 para sistemas heredados; evite DSA por completo.

¿Por qué se ha dejado de usar DSA para SSH?

Tres razones: 1) El protocolo SSH limita DSA a claves de 1024 bits (seguridad de aproximadamente 80 bits, por debajo del mínimo de 112 bits del NIST). 2) Las firmas DSA requieren un nonce aleatorio por firma; la reutilización o previsibilidad del nonce permite la recuperación de la clave privada (demostrado en PlayStation 3 y monederos de Bitcoin). 3) El NIST desaconsejó DSA para la generación de firmas en FIPS 186-5 (2023). OpenSSH 7.0+ desactiva DSA por defecto.

¿Cuál es la diferencia entre ECDSA y Ed25519 para SSH?

Ambos utilizan criptografía de curva elíptica con claves compactas. La principal diferencia radica en que Ed25519 genera firmas de forma determinista (hash de la clave privada y el mensaje, sin nonce aleatorio), eliminando así la clase de fallos de nonce que afecta a ECDSA. Ed25519 se ejecuta en tiempo constante (resiste ataques de canal lateral); la seguridad de ECDSA depende de la calidad del generador de números aleatorios. Se recomienda Ed25519 para nuevas implementaciones.

¿Cómo se deben rotar y gestionar las claves SSH a escala empresarial?

Requisitos: inventario centralizado que asigne cada entrada de authorized_keys a un propietario; programación de rotación definida por políticas (mínimo anual; inmediatamente en caso de salida, vulneración o descontinuación); generación, distribución y eliminación automatizadas de claves; y registro de auditoría continuo. La gestión manual en cientos de servidores no es escalable; las plataformas de gestión de claves SSH gestionan el descubrimiento, la rotación y la revocación de forma centralizada.

¿Son las claves SSH vulnerables a los ataques de computación cuántica?

Sí. Los cuatro algoritmos son vulnerables al algoritmo de Shor en una computadora cuántica. OpenSSH 10.0 introdujo mlkem768x25519-sha256 como intercambio de claves predeterminado (clásico híbrido + ML-KEM-768) para proteger la confidencialidad de la sesión. Las claves de autenticación SSH post-cuánticas aún están en desarrollo; Ed25519 sigue siendo la mejor opción de autenticación en la actualidad.

¿Qué marcos de cumplimiento rigen la selección del algoritmo de clave SSH?

NIST SP 800-53 (Protección de sistemas y comunicaciones); NIST SP 800-57 (gestión de claves); Requisito 2.2.7 de PCI DSS v4.0 (criptografía robusta para acceso administrativo sin consola); FIPS 186-5 (DSA formalmente obsoleto); NIST SP 800-131A (algoritmos aprobados: RSA-2048 mínimo, Ed25519 y ECDSA P-256+ aprobados).