Las claves SSH son una parte fundamental del acceso remoto seguro, pero muchos equipos aún las utilizan sin comprender completamente las ventajas y desventajas de los algoritmos disponibles. Elegir el tipo de clave SSH adecuado es importante porque afecta la seguridad, la compatibilidad, el rendimiento y el mantenimiento a largo plazo. A partir de 2025, los algoritmos de autenticación SSH más adoptados son RSA, ECDSA y EdDSA (Ed25519), mientras que DSA ha sido obsoleto y deshabilitado en todas las implementaciones modernas de SSH. En entornos regidos por marcos de cumplimiento como PCI-DSS, NIST SP 800-53 o SOC 2La elección del algoritmo de clave SSH puede afectar directamente los resultados de las auditorías y la postura regulatoria, lo que convierte la selección del algoritmo en una cuestión tanto técnica como de gobernanza.
Este blog explica en detalle los cuatro algoritmos de clave SSH con los que es más probable que te encuentres: RSA, DSA, ECDSA y EdDSA. EdDSA es una familia de esquemas de firma digital en lugar de un solo algoritmo, con diferentes variantes instanciadas sobre diferentes curvas elípticas; las dos estandarizadas en RFC 8032 son Ed25519 (basada en Curve25519, que ofrece una seguridad de aproximadamente 128 bits) y Ed448 (basada en Curve448, que ofrece una seguridad de aproximadamente 224 bits para cargas de trabajo de mayor seguridad).
En la práctica de SSH, EdDSA casi siempre se refiere a Ed25519, por lo que ambos términos se usan a menudo indistintamente. Esta guía explica los fundamentos criptográficos, las fortalezas, las debilidades y la aplicabilidad práctica de cada algoritmo. Ya sea que sea un administrador de sistemas que refuerza los servidores de producción, un ingeniero de DevOps que crea pipelines de CI/CD o un consultor de seguridad que audita la infraestructura SSH de una empresa, le ayudará a tomar una decisión informada sobre qué tipo de clave implementar y cuándo migrar a una nueva versión.
¿Qué son las claves SSH?
Llaves 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 a través de la red. Cada par tiene una llave privada que permanece en tu dispositivo y un Llave pública que se copia al servidor o servicio al que desea acceder. Al conectarse, el servidor verifica que usted posee la clave privada correspondiente a la clave pública autorizada.
La seguridad de la autenticación de clave SSH se basa en criptografía asimétrica (de clave pública)La clave privada y la clave pública están vinculadas matemáticamente de tal manera que un mensaje firmado con la clave privada solo puede verificarse con la clave pública correspondiente; sin embargo, la clave privada no puede derivarse de la clave pública en un tiempo razonable. Esta asimetría permite que la clave privada permanezca secreta en el cliente, mientras que la clave pública se distribuye libremente a todos los servidores a los que el usuario necesita acceder.
El algoritmo específico —RSA, DSA, ECDSA o EdDSA— define el problema matemático sobre el que se basa esta asimetría y, por lo tanto, determina cómo se generan las firmas, cómo se verifican y cuánto esfuerzo computacional requiere cada operación.
Bajo el capó, el Autenticación SSH El apretón de manos funciona de la siguiente manera:
- El cliente inicia una conexión SSH con el servidor y presenta su clave pública.
- El servidor comprueba si esa clave pública está listada en la claves_autorizadas archivo para la cuenta de usuario de destino.
- Si se encuentra la clave, el servidor genera un desafío aleatorio y lo cifra o firma utilizando la clave pública del cliente.
- El servidor envía el desafío al cliente.
- El cliente descifra o firma el desafío utilizando su clave privada y envía la respuesta de vuelta al servidor.
- El servidor verifica la respuesta, confirmando que el cliente posee la clave privada correspondiente sin que la clave en sí se transmita en ningún momento a través de la red.
Vale la pena señalar que las claves SSH no solo se utilizan para inicios de sesión interactivos. También protegen las transferencias de archivos (SCP, SFTP), reenvío de puertos, tunelización, operaciones Git y comunicación automatizada máquina a máquina.
Los cuatro algoritmos
En la práctica, se suelen mencionar cuatro tipos de claves SSH: RSA, DSA, ECDSA y EdDSA. De estas, RSA es la opción predeterminada histórica, DSA es la opción heredada, ECDSA es una alternativa de curva elíptica y EdDSA, generalmente representada por Ed25519 en SSH, es la opción predeterminada moderna para la mayoría de las configuraciones nuevas. Las herramientas de OpenSSH reflejan este cambio: ssh-keygen admite RSA, ECDSA y Ed25519, y las versiones modernas utilizan Ed25519 por defecto cuando no se especifica ningún tipo.
RSA
RSA se basa en la dificultad matemática de factorizar números enteros muy grandes en números primos. Por ello, la seguridad de RSA depende en gran medida de la longitud de la clave; las claves antiguas de 1024 bits ya no se consideran seguras, mientras que las de 3072 o 4096 bits son más adecuadas para el uso actual. OpenSSH aún admite claves RSA y ssh-keygen permite generarlas con la opción -t rsa.
Fortalezas de RSA
La principal ventaja de RSA es su compatibilidad. Funciona con servidores, dispositivos de red, herramientas de automatización y productos empresariales antiguos que podrían no ser compatibles con los algoritmos más recientes. Si opera en un entorno con infraestructura de diferentes generaciones, RSA suele ser la opción menos disruptiva.
Otra ventaja es su madurez. RSA se ha estudiado durante décadas y muchos administradores se sienten cómodos auditando, rotando y solucionando problemas de acceso SSH basado en RSA. Esta familiaridad sigue siendo importante en grandes empresas, donde el riesgo operativo puede ser más relevante que la elegancia criptográfica.
Limitaciones de RSA
Las claves RSA son mucho más grandes que las claves de curva elíptica, lo que implica mayor capacidad de almacenamiento, mayor ancho de banda y operaciones ligeramente más lentas. Para la autenticación SSH, esto suele ser aceptable, pero a gran escala puede generar una sobrecarga en comparación con algoritmos más recientes. Además, muchos de los debates sobre la obsolescencia de RSA se refieren en realidad al antiguo esquema de firma SHA-1 de ssh-rsa, más que a RSA en sí; la versión moderna de RSA aún puede utilizarse con firmas SHA-2.
Ejemplo de la vida real
Un caso de uso común de RSA es un servidor bastión heredado en un entorno financiero o industrial. Supongamos que usted administra un dispositivo de red de un proveedor antiguo que solo acepta claves RSA. En ese caso, una clave RSA de 4096 bits puede ser la única opción práctica hasta que se actualice el hardware o el firmware.
DSA
DSA fue en su momento un algoritmo de firma digital estándar y se utilizó históricamente en SSH, pero hace tiempo que cayó en desuso. En OpenSSH y en la mayoría de las guías modernas, DSA se considera una opción obsoleta en lugar de una recomendada.
¿Por qué se desaconseja el uso de DSA?
El uso de DSA se desaconseja por varias razones concretas y bien documentadas. En primer lugar, el protocolo SSH limita estrictamente las claves DSA a 1024 bits de, lo que corresponde a solo unos 80 bits de seguridad equivalente simétrica, muy por debajo del mínimo de 112 bits que el NIST ha requerido para cualquier nuevo trabajo criptográfico desde 2014. En segundo lugar, las firmas DSA dependen críticamente de un valor aleatorio secreto por firma conocido como nuncio apostólicoSi ese valor aleatorio se repite o es predecible, aunque sea ligeramente, la clave privada se puede recuperar algebraicamente a partir de solo dos firmas.
Los incidentes del mundo real (desde el jailbreak de PlayStation 3 hasta las carteras de Bitcoin comprometidas) han demostrado repetidamente esta clase de fallos. En tercer lugar, el NIST formalmente DSA obsoleto para la generación de firmas en FIPS 186-5 (2023), permitiendo únicamente la verificación de versiones anteriores, lo que convierte a las claves DSA en un riesgo de cumplimiento en cualquier entorno regulado.
La postura de OpenSSH refleja directamente estas debilidades: OpenSSH 7.0 y versiones posteriores desactivan el algoritmo de clave pública ssh-dss (DSA). Con el argumento de que es débil, el proyecto desaconseja su uso. En cualquier sistema mínimamente moderno, las claves DSA simplemente no funcionarán sin volver a habilitar explícitamente un algoritmo obsoleto, lo cual indica que se trata de un problema de migración, no de una decisión de diseño.
Ejemplo de la vida real
Es posible que aún encuentre DSA en un entorno heredado donde un servidor antiguo nunca se haya modernizado. Por ejemplo, un laboratorio universitario, un sistema de compilación interno antiguo o un dispositivo de un proveedor pueden tener una clave DSA configurada hace años. En esos casos, la respuesta adecuada suele ser planificar la migración, no seguir adoptándolo.
ECDSA
ECDSA utiliza criptografía de curva elíptica, que proporciona una seguridad robusta con claves mucho más pequeñas que RSA. Las implementaciones de SSH suelen admitir tamaños de curva como 256, 384 y 521 bits, y ssh-keygen aplica estos tamaños específicos. Esto hace que ECDSA sea eficiente y compacto.
Fortalezas de ECDSA
ECDSA resulta atractivo porque ofrece un buen rendimiento y claves de menor tamaño, lo que puede ser útil en entornos con recursos limitados. Claves más pequeñas implican menos datos que almacenar, copiar y transmitir, lo cual puede ser importante en sistemas embebidos, flujos de trabajo automatizados o grandes flotas de servidores.
Limitaciones de ECDSA
ECDSA Es más sensible a la correcta implementación y selección de curvas que Ed25519. Si bien sigue siendo seguro cuando se implementa correctamente, muchos equipos prefieren Ed25519 porque es más simple, más difícil de usar incorrectamente y, en general, más ergonómico en las herramientas modernas. ECDSA también carece de la comodidad de "simplemente funciona" que Ed25519 ofrece en los flujos de trabajo SSH actuales.
Ejemplo de la vida real
Un caso de uso realista de ECDSA es un entorno de producción con recursos limitados donde el tamaño de la clave es importante, como un conjunto de máquinas virtuales pequeñas o dispositivos integrados. Si la pila de software ya admite curvas elípticas y se necesitan credenciales compactas, ECDSA es una opción razonable. Sin embargo, si se empieza desde cero, Ed25519 suele ser la mejor opción predeterminada.
EdDSA / Ed25519
EdDSA es un esquema de firma digital moderno y, en la práctica de SSH, casi siempre se hace referencia a Ed25519. OpenSSH añadió compatibilidad con Ed25519 en la versión 6.5 y lo describió como un sistema que ofrece mayor seguridad que ECDSA y DSA, con un buen rendimiento. Los generadores de claves SSH modernos utilizan Ed25519 por defecto, ya que actualmente se considera el mejor tipo de clave SSH de uso general.
Puntos fuertes de Ed25519
Ed25519 es rápido, compacto y seguro por defecto. Cuenta con claves pequeñas, operaciones eficientes y un diseño que reduce muchos de los inconvenientes asociados a los esquemas más antiguos. Para el uso diario —desarrolladores que acceden a servidores, administradores que se conectan a sistemas de acceso seguro o sistemas de automatización que acceden a la infraestructura— Ed25519 suele ser la mejor combinación de seguridad y comodidad.
Limitaciones de Ed25519
La principal limitación reside en la compatibilidad con sistemas antiguos. Los servidores, dispositivos o servicios gestionados SSH muy antiguos podrían no ser compatibles con Ed25519, lo que obliga a los equipos a mantener RSA como alternativa. Dicho esto, los problemas de compatibilidad son cada vez menos frecuentes, ya que más plataformas de software adoptan OpenSSH y bibliotecas criptográficas modernas.
Ejemplo de la vida real
Un ejemplo típico actual es el de un ingeniero de software que genera una clave SSH personal para GitHub, GitLab o un servidor de seguridad de producción. En ese caso, `ssh-keygen -t ed25519` suele ser la opción más adecuada, ya que es segura, rápida y fácil de gestionar. Los equipos también la prefieren para la automatización, puesto que reduce la fricción operativa sin debilitar la autenticación.
Comparación lado a lado
| Algoritmo | Seguridad | Rendimiento | Tamaño clave | Compatibilidad | Recomendado para |
| RSA | Fuerte a 3072+ bits (SHA-2) | Generador de claves y firma lentos | Ancha | Excelente | Sistemas heredados y máxima compatibilidad |
| DSA | Débil (1024 bits, seguridad de ~80 bits) | Lento, dependiente de nonce | Moderado | Deshabilitado en OpenSSH 7.0+ | Solo sistemas antiguos que no se pueden cambiar |
| ECDSA | Fuerte (sensible a los medicamentos no perecederos) | Rápido | Pequeña | Bueno | Entornos restringidos o implementaciones ECDSA existentes |
| EdDSA / Ed25519 | Muy robusto (~128 bits, determinista) | Muy rápido | Muy pequeña | Sólidos conocimientos en herramientas modernas | Nuevas configuraciones SSH y uso general |
¿Cuál deberías elegir?
Elegir un algoritmo de clave SSH rara vez es una decisión que sirva para todos los casos. La opción correcta depende de lo que se desea proteger, de la infraestructura existente y de la cantidad de cambios operativos que se estén dispuestos a asumir a corto plazo. Las secciones siguientes analizan la decisión según el escenario: nuevas implementaciones, compatibilidad con sistemas heredados, casos especiales y una estrategia de migración práctica, para que pueda adaptar el algoritmo a su entorno.
Para nuevos sistemas
Para nuevas claves SSH, elija Ed25519. Ofrece el mejor equilibrio entre seguridad, rendimiento y simplicidad, y es la recomendación predeterminada en la mayoría de las guías SSH modernas. Si no existen restricciones de compatibilidad con versiones anteriores, Ed25519 debería ser su primera opción.
Para compatibilidad con versiones anteriores
Elija RSA cuando necesite conectarse a servidores, dispositivos o software antiguos que no sean compatibles con Ed25519. En esos entornos, RSA sigue siendo el puente de compatibilidad más seguro, especialmente cuando se utiliza un método de firma SHA-2 moderno en lugar de la variante ssh-rsa anterior basada en SHA-1.
Para casos especiales
Utilice ECDSA únicamente cuando necesite específicamente una opción de curva elíptica y sepa que su entorno la admite correctamente. Evite por completo DSA para proyectos nuevos y considérelo un problema de migración en lugar de una decisión de diseño.
Estrategia práctica de migración
Si su organización aún utiliza claves SSH de diferentes tipos, una ruta de migración recomendable es ejecutar tanto RSA como Ed25519 durante la transición. Mantenga RSA solo para los sistemas que aún no admiten Ed25519 y elimínelo gradualmente a medida que se actualicen dichos sistemas. Esto evita interrupciones del servicio y, al mismo tiempo, permite modernizar el entorno con criptografía avanzada.
Un despliegue práctico podría ser así:
- Genera una nueva clave Ed25519 para tu identidad SSH principal.
- Conserva una clave RSA únicamente para los sistemas antiguos que aún la requieran.
- Agregue ambas claves públicas a authorized_keys donde sea necesario.
- Supervise qué teclas siguen en uso.
- Retire RSA una vez que ya no sea necesaria la compatibilidad.
Consideraciones post-cuánticas
Cabe destacar que los cuatro algoritmos de clave SSH analizados en este blog —RSA, DSA, ECDSA y EdDSA— son vulnerables a ataques de ordenadores cuánticos suficientemente potentes. El algoritmo de Shor, si se implementara en un ordenador cuántico a gran escala, podría resolver problemas de factorización de enteros (RSA, DSA) y de logaritmo discreto en curvas elípticas (ECDSA, EdDSA) en tiempo polinomial. Si bien estos ordenadores cuánticos aún no existen, las organizaciones con requisitos de confidencialidad a largo plazo deberían comenzar a planificar la criptografía postcuántica (PQC).
El NIST ha estado estandarizando algoritmos criptográficos postcuánticos y el proyecto OpenSSH ya ha comenzado a experimentar con métodos híbridos de intercambio de claves que combinan algoritmos clásicos con candidatos postcuánticos. OpenSSH 9.0 introdujo un intercambio de claves híbrido Streamlined NTRU Prime + X25519 como predeterminado, lo que protege el intercambio de claves de sesión contra futuros ataques cuánticos. Sin embargo, las claves de autenticación SSH postcuánticas aún se encuentran en una fase temprana de desarrollo. Por ahora, usar Ed25519 para la autenticación sigue siendo la mejor opción práctica, entendiendo que eventualmente será necesaria una transición a firmas postcuánticas.
Intercambio de claves post-cuántico (KEX) en SSH
Si bien la poscuántica autenticación aún está madurando, post-cuántico intercambio de llaves ya ha entrado en producción. En abril de 2025, OpenSSH 10.0 fue lanzado con un intercambio de claves post-cuántico híbrido, mlkem768x25519-sha256, activado por defectoEsto combina el clásico X25519 Intercambio Diffie-Hellman con ML-KEM-768, el mecanismo de encapsulación de clave post-cuántica estandarizado por NIST basado en CRYSTALS-Kyber (FIP 203). La construcción híbrida proporciona defensa en profundidad: la clave de sesión se deriva de ambos componentes, por lo que el intercambio permanece seguro siempre que ya sea El algoritmo se mantiene vigente: una póliza de seguro sensata mientras la comunidad criptográfica genera confianza en las primitivas post-cuánticas.
Esto importa específicamente debido a Cosecha ahora, descifra después. Ataques: los adversarios capaces de registrar las sesiones SSH cifradas actuales podrían, una vez que exista una computadora cuántica con capacidad criptográfica, descifrarlas retroactivamente. El protocolo de intercambio de claves es fundamental para la confidencialidad de toda la sesión, por lo que su actualización es el paso más urgente en la era poscuántica. Si su organización utiliza OpenSSH 10.0 o posterior, mlkem768x25519-sha256 ya le ofrece protección. En versiones anteriores (de la 9.0 a la 9.9), está disponible el método híbrido sntrup761x25519-sha512, que debería preferirse a los métodos de intercambio de claves clásicos para sesiones de larga duración o tráfico de alta sensibilidad.
En términos prácticos, el mensaje es claro: Ed25519 sigue siendo la opción correcta. hoy Para las claves de autenticación SSH, combínelo con una versión moderna de OpenSSH (10.0 o superior) para que el intercambio de claves de sesión sea resistente a la computación cuántica. Cuando los algoritmos de firma post-cuántica aprobados por el NIST (ML-DSA / CRYSTALS-Dilithium, FIPS 204) lleguen a OpenSSH para la autenticación, la migración será gradual en lugar de disruptiva.
¿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. Nuestra solución, SSH seguroEstá diseñada para ofrecer seguridad integral durante todo el ciclo de vida de las claves, proporcionar visibilidad completa y garantizar que las organizaciones puedan gestionarlas con confianza y sin complicaciones adicionales. Así es como le ayudamos:
1. Visibilidad centralizada y mapeo de propiedad
Mediante una combinación de descubrimiento con y sin agente, SSH Secure localiza cada clave SSH en servidores y equipos de usuario. Todas las claves se almacenan en un único inventario con información de propiedad y uso, lo que elimina las claves huérfanas y reduce... expansión de claves y garantizando la plena rendición de cuentas 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 gobernanza del ciclo de vida elimina las claves débiles o obsoletas y 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 se almacenan de forma segura en módulos de seguridad de hardware (HSM), lo que garantiza su inexportabilidad y resistencia a manipulaciones. Las claves se generan mediante algoritmos criptográficos robustos como RSA-4096, ECDSA y Ed25519, lo que proporciona una sólida protección, resistencia a ataques de fuerza bruta y eficiencia.
El uso de HSM también es muy eficaz contra el robo de memoria y los ataques de vulnerabilidad del sistema operativo. Incluso si el malware accede al sistema operativo host o intenta leer la memoria del proceso, las claves privadas permanecen aisladas dentro del sistema. HSMNunca se exponen a la RAM ni al disco, por lo que los atacantes no pueden extraerlas de la memoria del sistema, la caché ni el espacio de intercambio. Este aislamiento basado en hardware reduce drásticamente el riesgo en comparación con el almacenamiento de claves exclusivamente por software y proporciona protección incluso en escenarios de vulneración del sistema operativo con privilegios elevados o de administrador.
5. Control basado en políticas para operaciones clave
Todas las operaciones clave, como la generación, los flujos de trabajo 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 dar soporte a los modelos de gobernanza internos.
6. Monitoreo continuo, auditoría y preparación para el cumplimiento
SSH Secure ofrece monitorización en tiempo real de las actividades clave con registro detallado de eventos y detección de anomalías integrada. Los registros se integran con los paneles de Splunk o Loki-Grafana para una visualización, correlación y alertas avanzadas. Las capacidades de auditoría flexibles incluyen registros descargables e informes detallados, lo que proporciona a los equipos de seguridad información clara sobre el uso de las claves y la postura 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
La selección de claves SSH no es simplemente una preferencia técnica; es una decisión de seguridad que afecta la integridad del acceso remoto, la resiliencia de los flujos de trabajo automatizados y el cumplimiento normativo de su organización. Cada uno de los cuatro algoritmos analizados en este blog tiene un perfil distinto: RSA Ofrece compatibilidad probada en combate y sigue siendo necesaria para entornos heredados; DSA es un algoritmo obsoleto del que se debe migrar lo antes posible; ECDSA proporciona criptografía de curva elíptica eficiente, pero conlleva complejidad de implementación y preocupaciones persistentes sobre la procedencia de la curva NIST; y Ed25519 ofrece la mejor combinación de seguridad, rendimiento, simplicidad y soporte de herramientas modernas.
Para la gran mayoría de las nuevas implementaciones de SSH, Ed25519 es la recomendación indiscutible. Elimina categorías enteras de vulnerabilidades de implementación mediante la generación determinista de nonce, ofrece los tamaños de clave más pequeños de cualquier algoritmo convencional, se ejecuta en tiempo constante para resistir ataques de canal lateral y es la opción predeterminada en OpenSSH moderno. Las organizaciones que aún dependen de RSA deben asegurarse de usar claves de 4096 bits con firmas SHA-2 y planificar un cronograma de migración hacia Ed25519. Cualquier clave DSA restante debe tratarse como una prioridad de corrección.
De cara al futuro, el panorama criptográfico seguirá evolucionando. La criptografía postcuántica se vislumbra en el horizonte y las implementaciones de SSH ya están empezando a incorporar mecanismos híbridos de intercambio de claves. Sin embargo, los fundamentos de una buena gestión de claves —el uso de algoritmos robustos, la rotación periódica de claves, la aplicación del principio de mínimo privilegio, la auditoría del uso de claves y el mantenimiento de un inventario claro de todas las credenciales SSH— seguirán siendo esenciales, independientemente de los algoritmos que depare el futuro. Al elegir Ed25519 hoy y mantener un enfoque riguroso para la gestión del ciclo de vida de las claves SSH, su infraestructura estará preparada tanto para la seguridad actual como para una transición más fluida hacia lo que venga después.
