SSH se usa ampliamente y se considera el estándar para administrar sistemas Linux de forma remota; sin embargo, fue diseñado en 1995, cuando un puñado de personas accedían a las computadoras en una red local. Para ayudar a que SSH escale a la escala actual de la nube, resulta imposible utilizar claves SSH heredadas que no caduquen; es por eso que organizaciones como Facebook, Uber, Netflix y Keytos han hecho la transición a Certificados SSH.
La experiencia de usuario con SSH está lejos de ser ideal. Configurar nuevos usuarios es un proceso lento y manual. Las alertas de seguridad al conectarse a nuevos hosts suelen ser desconcertantes y dejan a los usuarios con credenciales desconocidas y pocos consejos sobre cómo manejarlas.
Gestionar SSH a gran escala es problemático. El proceso de aprobación y distribución de claves es ineficiente y requiere mucho tiempo. Reutilizar nombres de host simplemente no es posible. Las herramientas caseras distribuyen información clave a través de su red, creando un desorden que necesita limpieza al eliminar usuarios y seamos honestos, ¿cuándo fue la última vez que rotó su clave compartida cuando un usuario se fue?
SSH tiende a promover malos hábitos de seguridad, haciendo de SSH uno de los puntos más débiles de su infraestructura. Dado que el cambio de claves es complejo, con frecuencia se evita. Los usuarios a menudo tienen acceso directo al material clave y deben reutilizarlas en múltiples dispositivos. Las claves son de confianza permanente, lo que significa que los errores generan vulnerabilidades.
Sabemos que ahora mismo tienes náuseas, ¡pero deja el ginger ale! ¡Estos problemas se pueden resolver! Si bien ninguno de estos problemas es inherente al propio SSH, sí surgen de cómo se implementa la autenticación de clave pública SSH. La respuesta a estos problemas radica en la transición a la autenticación de certificados. El uso de la autenticación de certificados SSH simplifica el uso, mejora el funcionamiento y mejora la seguridad.
En Keytos, hemos estado recomendando utilizar certificados SSH durante toda nuestra vida (¡incluso hablamos de ellos en uno de nuestros primeros blogs!). Dicho esto, ¿otras personas y organizaciones están tomando nota de los certificados SSH tal como lo hemos hecho nosotros?
La respuesta corta es sí. Prácticamente todas las organizaciones que operan a escala y tienen un buen conocimiento de la ciberseguridad utilizan certificados SSH (por ejemplo Facebook, Uber y Netflix).
Por supuesto, esas son las empresas más grandes con las redes de información más grandes: ¿por qué no estarían al tanto de los últimos acontecimientos en el mundo de SSH? Sin embargo, para las organizaciones pequeñas o medianas resulta más difícil mantenerse al día con las tendencias de SSH. Después de todo, los certificados y la PKI son bastante difíciles de entender y la gente no siempre ve las ventajas de inmediato. Además, los certificados SSH no han recibido la atención que merecen. La mayoría de las personas ajenas a estas grandes organizaciones que se actualizan constantemente ni siquiera han oído hablar de ellas.
Por eso estamos aquí. Educar. Para informar. ¡Para difundir las ventajas de los certificados SSH! Antes de que podamos profundizar en por qué los certificados SSH son los mejores, es importante comprender primero la diferencia entre autenticación de clave pública y autenticación de certificado.
La mayoría de las configuraciones SSH utilizan autenticación de clave pública. Este método emplea criptografía asimétrica (clave pública), creando un par de claves pública/privada único para cada usuario y host con fines de autenticación. La característica clave de la criptografía asimétrica radica en la relación única entre una clave pública y una privada. Los datos firmados con una clave privada se pueden verificar utilizando la clave pública correspondiente. Al igual que el hash, es prácticamente imposible falsificar una firma; por lo tanto, si se puede verificar una firma y se conoce el propietario de la clave privada, se confirma el origen de la firma.
Se puede lograr una forma básica de autenticación pidiendo a alguien que firme un gran número generado aleatoriamente. Por ejemplo, si estableciera una conexión con usted, le enviara un número aleatorio y usted me devolviera una firma válida de ese número, eso confirmaría que me estoy comunicando con usted. Si bien esta es una explicación bastante simplificada, describe en términos generales cómo funciona la autenticación de clave pública SSH. La autenticación de certificados funciona de manera similar, con una diferencia clave que se analizará en breve.
Para utilizar SSH con autenticación de clave pública, el host debe reconocer su clave pública. Normalmente, su clave pública debe colocarse en ~/.ssh/authorized_keys. Administrar este archivo para numerosos usuarios en una red es complejo y propenso a errores.
El inicio de SSH con autenticación de clave pública a menudo comienza con una secuencia complicada de comandos ssh-keygen, generalmente obtenidos de una guía o, más comúnmente, de foros en línea. El siguiente paso consiste en enviar su clave pública para su aprobación y distribución, lo que suele ser un proceso manual y no transparente. Es posible que deba enviar un correo electrónico a un administrador o crear un ticket de asistencia técnica y luego esperar. Divertido, lo sabemos. Mientras tanto, un operador tiene la tarea de agregar su clave a un directorio en un repositorio e iniciar una implementación. Una vez completado esto, obtendrá acceso SSH. Dado que estas asociaciones clave son permanentes, su acceso SSH permanece activo indefinidamente (a menos que alguien lo elimine activamente).
La autenticación de certificados elimina la necesidad de aprobación y distribución de claves. En lugar de dispersar claves públicas a través de archivos estáticos, asocia una clave pública con una identidad específica mediante un certificado. Un certificado es esencialmente un formato de datos que abarca una clave pública, una identidad e información adicional como una fecha de vencimiento y permisos. Este formato de datos luego es firmado por una CA.
$ ssh-keygen -L -f testkey-cert.pub
testkey-cert.pub:
Type: ecdsa-sha2-nistp256-cert-v01@openssh.com user certificate
Public key: ECDSA-CERT SHA256:O6M6oIjDm5gPm1/aTY619BgC3KSpS4c3aHVWxYh/uGQ
Signing CA: ECDSA SHA256:BE2EXJGoPv2LA6yEbjH+sf9JjG9Rd45FH1Wt/6H1k7Y
Key ID: "brett@example.com"
Serial: 4309395459650363134
Valid: from 2023-11-11T11:11:11 to 2023-11-11T12:11:11
Principals:
root
Critical Options: (none)
Extensions:
permit-X11-forwarding
permit-agent-forwarding
permit-port-forwarding
permit-pty
permit-user-rc
Para activar la autenticación de certificados, configure tanto los clientes como los hosts para autenticar certificados con la clave pública de su CA, lo que significa que deben confiar en los certificados emitidos por su CA. En cada host, debe modificar el archivo /etc/ssh/sshd_config. Esto implica especificar la clave pública de la CA para verificar los certificados de usuario, así como la clave privada y el certificado del host, como se ve en el siguiente ejemplo de código:
# Path to the CA public key for verifying user certificates
TrustedUserCAKeys /etc/ssh/ssh_user_key.pub
Para citar la pantalla final de Looney Tunes, “¡Eso es todo, amigos!” Eso es todo lo que tienes que hacer para comenzar a emplear la autenticación de certificados SSH, bueno, aquí tienes una versión más detallada sobre cómo crear tu propia Autoridad de Certificación SSH. Si lo desea, puede incluso usarlo junto con la autenticación de clave pública para facilitar el proceso de transición.
Probablemente se esté preguntando: “Eso es genial y todo eso, pero ¿por qué debería utilizar la autenticación de certificado en su lugar?” Nos alegra que hayas preguntado.
Eliminar la necesidad de aprobación y distribución de claves SSH brinda ventajas operativas inmediatas. Libera recursos operativos de tareas repetitivas de administración de claves y elimina los gastos continuos involucrados en monitorear y mantener soluciones personalizadas para agregar, eliminar, sincronizar y auditar archivos de claves públicas estáticas en toda su red.
Además, la opción de emitir certificados de usuario SSH a través de varios métodos de autenticación mejora la automatización operativa. Esto significa que los procesos automatizados como trabajos cron o scripts que requieren acceso SSH pueden asegurar un certificado SSH temporal según sea necesario, en lugar de depender de una clave privada estática preestablecida y de larga duración.
El protocolo SSH es fundamentalmente seguro, pero la autenticación de clave pública fomenta varias prácticas de seguridad deficientes, lo que dificulta mantener una higiene de seguridad óptima. En la autenticación de clave pública, las claves se confían indefinidamente. Esto significa que una clave comprometida o autorizada incorrectamente puede permanecer sin ser detectada o sin abordar durante un período prolongado. La falta de una gestión adecuada de las claves, como no eliminar las claves de los antiguos empleados, hace que SSH sea vulnerable al acceso no autorizado.
Por el contrario, los certificados tienen fechas de vencimiento. En cualquier incidente, ya sea un error, robo, uso indebido o filtración de claves, las credenciales SSH comprometidas dejarán de ser válidas automáticamente después de un cierto período, incluso si el incidente no se detecta ni se informa. Los certificados SSH están diseñados para ser a prueba de fallos; el acceso termina naturalmente a menos que se renueve activamente. Además, las consultas periódicas con su CA para la renovación de credenciales crean un seguimiento de auditoría automático.
La nueva clave para los usuarios también es engorrosa con la autenticación de clave pública. Lo tedioso de la aprobación y distribución de claves disuade a los usuarios de cambiar las claves, a pesar de las herramientas disponibles. Esto lleva a la práctica riesgosa de copiar y reutilizar claves privadas entre dispositivos, a veces durante períodos prolongados. Esta reutilización de claves supone un riesgo de seguridad importante. Las claves privadas nunca deben transferirse a través de redes, pero la autenticación de clave pública expone a los usuarios a estas claves confidenciales y no proporciona herramientas efectivas de administración de claves, lo que propicia el uso indebido y el abuso.
Una CA SSH, junto con un cliente fácil de usar, puede agilizar la generación de claves y proteger a los usuarios de muchas complejidades. Si bien la autenticación de certificados no elimina todos los riesgos de seguridad, admite flujos de trabajo SSH que son más sencillos, fáciles de usar y menos propensos a errores.
En Keytos, creemos firmemente que los certificados SSH son la columna vertebral del flujo SSH óptimo.
Para realizar SSH, los usuarios comienzan ejecutando un comando de inicio de sesión en su terminal. Esto activa la apertura de un navegador y el inicio de un proceso de SSO dentro del proveedor de identidad de su organización.
El uso de un proceso SSO basado en web simplifica la integración de métodos robustos de MFA (autenticación multifactor) como FIDO U2F, junto con otras funciones de autenticación avanzadas ofrecidas por el proveedor de identidad. Los usuarios inician sesión mediante un procedimiento familiar y, al eliminar a un usuario del sistema de identidad principal, se revoca rápidamente su acceso SSH.
Después de completar el SSO, el usuario recibe un token de portador (como un token de identidad OIDC), que utiliza la utilidad de inicio de sesión. Luego, esta utilidad crea un nuevo par de claves y solicita un certificado firmado a la CA, autenticando y autorizando la solicitud con el token de portador.
La CA emite un certificado válido por aproximadamente un día laborable (entre 16 y 20 horas). La utilidad de inicio de sesión carga automáticamente el certificado firmado y su clave privada correspondiente en el ssh-agent del usuario.
Los usuarios no necesitan conocer estos detalles. Sólo necesitan entender que para acceder a SSH, primero deben ejecutar EZSSH. Después de esto, pueden usar SSH como de costumbre:
$ ezssh ssh -e brett@10.7.0.1
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 4.15.0-1036-gcp x86_64)
Last login: Wed Dec 20 04:05:55 2023 from 10.7.0.9
brett@pi:~$
Al igual que las cookies del navegador, los certificados de corta duración proporcionados son efímeros y duran lo suficiente para un día laboral. Iniciar sesión en SSH es similar a iniciar sesión en un sitio web; Es un proceso sencillo que debe realizarse como máximo una vez al día. Esta infrecuencia permite el uso de MFA fuerte sin que se convierta en una molestia o desensibilice a los usuarios.
Cada inicio de sesión genera nuevas claves privadas y certificados que nunca se almacenan en el disco. Colocarlos directamente en ssh-agent mantiene a los usuarios alejados de credenciales confidenciales (incluso puede configurarlo para que la clave no se guarde en ningún lugar, haciendo que sus certificados sean realmente de un solo uso). Si un usuario desea conectarse desde otro dispositivo, es más sencillo ejecutar EZSSH allí que transferir claves desde ssh-agent.
Si bien algunos críticos argumentan que la autenticación de certificados SSH es nueva, carece de un amplio soporte y no cuenta con herramientas prácticas, la realidad es diferente. La autenticación de certificados se introdujo en OpenSSH 5.4 hace casi 14 años. Está bien probado y empleado en operaciones a gran escala. Las herramientas necesarias para implementar este flujo de trabajo SSH ideal ya están disponibles.
EZSSH simplifica todo el proceso al eliminar la necesidad de manejar, actualizar y eliminar claves SSH para todos los usuarios en varios hosts. Esto se logra mediante el uso discreto de certificados SSH, mientras que los usuarios experimentan un inicio de sesión único (SSO) fluido utilizando su identidad AAD. Este enfoque garantiza que los usuarios ya no necesiten almacenar claves en sus computadoras personales, lo que reduce el riesgo de que estas claves se vean comprometidas por entidades maliciosas.
