Si fuera un jugador, apostaría todo mi bono de Navidad al hecho de que, si reuniera a 100 expertos en PKI en una sala y dijera las palabras “certificado digital”, el 90 por ciento de ellos automáticamente asumiría que estoy hablando de certificados digitales X.509. Esto tiene sentido: X.509 (también llamado certificados SSL/TLS) se habla hasta la saciedad en el mundo PKI. Por supuesto, los certificados X.509 no son el único tipo de certificado digital que existe: también existe el menos comentado certificado SSH! Los certificados X.509 facilitan la verificación de identidad en las interacciones entre navegador y servidor, mientras que los certificados SSH se utilizan para autenticar identidades en las comunicaciones entre un shell (terminal) y servidores Linux.
Es común encontrar ideas erróneas de que los certificados SSH son idénticos o intercambiables con los certificados X.509, pero esto es simplemente incorrecto. Este blog explorará de manera concisa la naturaleza de los certificados SSH, por qué debería usarlos y las diferencias fundamentales que los diferencian de los certificados X.509.
Hemos escrito mucho sobre los certificados SSH en el pasado, pero creemos que el tema es tan importante que merece escribir aún más sobre él; dicho esto, aquí hay una descripción general rápida de qué son los certificados SSH y cómo funcionan.
Cuando decodificas un certificado SSH, es esencialmente una estructura que contiene una clave pública, un nombre y, a veces, detalles adicionales como una fecha de vencimiento y permisos específicos. Los certificados SSH son bastante similares a los certificados X.509, pero tienen menos atributos.
Usar un certificado SSH es el método más seguro para el acceso SSH; sin embargo, su uso no está tan extendido como podría pensarse, posiblemente por el simple y triste hecho de que muchos desarrolladores los desconocen. Además, los certificados SSH exigen un mayor esfuerzo inicial en comparación con el método de clave SSH estándar, lo que tiende a disuadir a las personas de usarlos. Pero las ventajas que ofrecen los certificados SSH (particularmente para administrar numerosos usuarios, hosts y claves) hacen que la configuración inicial valga la pena.
Aunque OpenSSH introdujo la autenticación basada en certificados SSH en 2010, la mayoría de las personas todavía dependen de contraseñas o claves públicas para la autenticación SSH.
El uso de contraseñas para la autenticación SSH a menudo es criticado debido a la tendencia humana a elegir contraseñas débiles y fáciles de adivinar, lo que las hace susceptibles a la piratería. Además, durante el inicio de una conexión SSH, las contraseñas se envían directamente al servidor, dejándolos expuestos a ataques de fuerza bruta.
La autenticación de clave pública para SSH ofrece una opción más segura que las contraseñas, pero tampoco está exenta de posibilidades de uso indebido. En este sistema, tanto los clientes como los servidores deben poseer sus respectivos pares de claves públicas y privadas. Cuando un cliente intenta establecer una conexión SSH con un servidor, ocurren dos pasos críticos:
En primer lugar, el cliente comprueba si la clave pública del servidor está presente en su archivo known_hosts para verificar la confiabilidad del servidor. Si no se reconoce la clave pública del servidor, se produce un error que indica que no se puede establecer la autenticidad del servidor y pregunta si se debe continuar con la conexión de todos modos:
The authenticity of host 'xxx' can't be established.
RSA key fingerprint is SHA256:kfcwi9X8T4nMRw1OM0xDXETGcqjU26/zbM+KqNB6CKw.
Are you sure you want to continue connecting (yes/no)?
En tal escenario, la acción ideal es que el usuario verifique la huella digital de la clave con el administrador del servidor. Este paso es crucial porque existe la posibilidad de que un atacante haya vinculado una dirección IP ampliamente confiable a una máquina maliciosa. A pesar de esto, en la práctica, muchos usuarios optan por la ruta más sencilla y simplemente escriben “sí”. Al hacerlo, se forma una conexión con el servidor sin la autenticación adecuada y la clave pública del servidor se guarda permanentemente en el archivo known_hosts del cliente. Esto resalta una debilidad fundamental de la autenticación de clave SSH: promueve el antipatrón de “confianza en el primer uso” (TOFU). Y al igual que la comida, el TOFU está increíblemente sobrevalorado.
En segundo lugar, el servidor intenta autenticar al usuario verificando si la clave pública del usuario está en su archivo authorized_keys. Los miembros del equipo comúnmente envían su clave pública a un administrador para que la agregue al archivo authorized_keys en cada servidor necesario, pero ¿qué pasa si hay más de decenas de servidores donde estas claves deben implementarse? Esto introduce el segundo problema con la autenticación de claves SSH: la gestión de claves puede resultar tremendamente onerosa, ineficiente e inmanejable para las organizaciones más grandes. Además, el hecho de que las claves no tengan fecha de caducidad expone los sistemas a riesgos de seguridad. Por ejemplo, cuando un empleado deja una empresa, su clave pública debe eliminarse de todos los servidores; sin embargo, en realidad, esto no suele suceder. Estas conexiones clave vulnerables pueden permanecer sin ser detectadas durante largos períodos de tiempo, dejando el sistema abierto al acceso ilícito. Por ejemplo, Cisco tuvo un problema en el que un ex empleado eliminó cientos de máquinas virtuales después de ser despedido.
Varias soluciones comerciales y de código abierto tienen como objetivo abordar el tema de la gestión de claves. Su concepto principal es administrar claves a través de su servicio, supuestamente asegurando que, cuando se elimina una clave, se elimina de todos los servidores asociados; sin embargo, este enfoque tiene sus riesgos, ya que el servicio en sí podría convertirse en un punto singular de falla. Si un atacante obtiene el control de este servicio, ¡podría acceder a todos sus servidores! Como tal, en el peor de los casos, perder el acceso a este servicio significa perder también el acceso a todos sus servidores.
La autenticación basada en certificados SSH funciona de manera similar a los certificados X.509, pero tiene una configuración mucho más sencilla. Este método garantiza la autenticación mutua entre clientes y hosts, eliminando así el problema de TOFU.
Inicialmente, se establece un servidor de CA SSH (o una “CA en línea”), que contiene dos pares de claves de CA SSH: un par de claves de CA de host para firmar y verificar los certificados de la máquina host y un par de claves de CA de usuario para los certificados de cliente. En la terminología SSH, el término CA (autoridad de certificación) se utiliza a menudo para referirse tanto a los pares de claves de firma como al propio servidor SSH CA. ¡Cuanto más sepas!
Tener dos pares de claves de CA separados se considera la mejor práctica para minimizar el riesgo de ataques. En caso de que una clave privada se vea comprometida, solo necesitará volver a emitir certificados para sus hosts o usuarios, no para ambos simultáneamente.
Una vez creados los pares de claves de la CA del host y la CA del usuario, configure todas las máquinas host para que confíen en los certificados firmados por la clave pública de la CA del usuario. De manera similar, todos los clientes deben confiar en los certificados firmados por la clave pública de la CA anfitriona.
Para emitir certificados para máquinas host, genere pares de claves públicas y privadas para cada servidor y fírmelas utilizando las claves de CA del host. Para los certificados de cliente (usuario), genere pares de claves para cada cliente y fírmelos con las claves de CA del usuario. Idealmente, la emisión de certificados de usuario debería ser un proceso automatizado; por ejemplo, puede configurar un sistema como EZSSH donde los usuarios reciben certificados firmados automáticamente al autenticarse con el proveedor de identidad de su organización.
Cuando un cliente intenta conectarse a un host, presenta su certificado y el host corresponde. Los servidores host otorgan acceso sólo a clientes con certificados confiables, y los clientes pueden estar seguros de que se están conectando a un host verificado.
Más allá de eliminar el tedioso proceso de administración de claves y el problema TOFU, la autenticación de certificados SSH también brinda capacidades para un control de acceso detallado:
1) Los certificados tienen fechas de vencimiento. La emisión de certificados de corta duración reduce el peligro de que las claves comprometidas no utilizadas permanezcan activas. Por ejemplo, si un desarrollador abandona su organización sin que se le revoque el acceso, su certificado caducará automáticamente después de un tiempo determinado, revocando así su acceso.
2) Los certificados están designados para usuarios específicos (principales). Esta característica permite la implementación de control de acceso basado en roles, asegurando que los usuarios tengan permisos de acceso apropiados para sus roles.
3) Los certificados pueden incluir restricciones SSH específicas, como no permitir la asignación de PTY (pseudoterminal) o el reenvío de puertos, agregando una capa adicional de seguridad y control sobre las acciones del usuario.
Si esto es de tu interés y quieres profundizar en cómo configurar certificados SSH tú mismo, consulta nuestro blog sobre cómo crear certificados SSH por tu cuenta!
Ahora que comprendemos claramente los certificados SSH y su aplicación, exploremos en qué se diferencian de los certificados X.509; específicamente, echemos un vistazo a en qué se diferencian en su diseño, características e implementación.
Los certificados X.509 son versátiles y ampliamente aplicables: se emplean en una variedad de contextos, como SSL/TLS, S/MIME, EAP-TLS e incluso dentro del protocolo SSH. Su uso se extiende a aplicaciones web, bases de datos, VPN, Wi-Fi, firmas digitales para firma de documentos y mucho más.
Por el contrario, los certificados SSH se utilizan predominantemente para el acceso y la autenticación SSH, lo que destaca el diseño mucho más limitado de estos certificados en comparación con los certificados X.509.
En OpenSSH, los certificados SSH son más sencillos y tienen sólo un puñado de funciones. A diferencia de los certificados X.509 tradicionales, que vienen con una multitud de opciones y reglas de codificación complejas, los certificados SSH simplemente consisten en pares de claves públicas y privadas junto con información adicional de identidad y restricciones. A continuación se muestra una comparación de cómo se ven un certificado de usuario SSH decodificado y un certificado de cliente X509:
En el marco X.509, las CA tienen sus propios certificados y pueden incluir autoridades de certificación intermedias, un proceso conocido como encadenamiento de certificados. SSH, por otro lado, no permite tales complejidades. Su enfoque sencillo simplifica la configuración de certificados SSH y reduce las posibles vulnerabilidades de seguridad.
Además, SSH emplea dos tipos de formatos de certificado: el certificado de host y el certificado de usuario. Por el contrario, en X509, la función de un certificado se especifica como “autenticación de servidor” o “autenticación de cliente”, y se puede configurar un único certificado X509 para habilitar ambas.
