Los certificados SSH, como mencionamos en nuestro blog que describe los problemas con las claves SSH, son la mejor manera de evitar los muchos problemas que surgen con el uso de claves SSH. En este blog, profundizaremos en cómo funcionan los certificados SSH; Sin embargo, antes de que podamos hacer eso, debemos revisar la autenticación de clave pública.
La autenticación de clave pública contiene pares de claves criptográficas que tienen tanto una clave pública como una privada. Estas claves públicas y privadas están relacionadas matemáticamente de tal manera que usted puede verificar que alguien tiene la clave privada sin siquiera conocer la clave privada, siempre que tenga la clave pública. No se preocupe, no estamos aquí para aburrirlo con las complejidades matemáticas de la autenticación de clave pública, solo para repasar los conceptos básicos. Quizás en otro blog.
Ahora que hemos revisado los conceptos básicos de la autenticación de clave pública, deberíamos explicar exactamente cómo funciona SSH. Entonces, lo primero es lo primero: tienes un servidor y un cliente. El servidor contiene todas las claves públicas que están autorizadas para autenticarse en él en el archivo “claves_autorizadas”. Luego, cuando un usuario quiere autenticarse en ese servidor, ocurre lo siguiente:
1) La computadora del usuario envía una lista de cada clave pública que posee el usuario.
2) El servidor verifica si alguna de las claves está en el archivo “claves_autorizadas”.
3) Si el servidor puede hacer coincidir cualquiera de las claves con una clave en el archivo “claves_autorizadas”, el servidor crea un desafío.
4) La computadora del usuario utiliza la clave privada para completar el desafío del servidor y luego enviar la respuesta al servidor.
5) El servidor verifica el valor devuelto. Si el valor devuelto se puede validar, entonces se inicia la sesión.
Por supuesto, estos pasos fueron increíblemente simplificados con el fin de llegar a la explicación de los certificados SSH, pero (con suerte) entenderás la esencia general. Desafortunadamente, esto simplemente no escala. Claro, es excelente para proteger su servidor doméstico o algo a un nivel similar, pero no se puede decir lo mismo de ningún servidor o punto final con mayor complejidad. ¿Qué significa escalabilidad en este sentido? Un trabajo de tiempo completo. Cuando decimos escala en la nube, nos referimos a agregar y mantener las claves de las partes autorizadas que podrían necesitar acceder a un servidor en algún momento, para todos los miles o millones de servidores que una empresa puede tener. Esto es lo que llevó a la creación de certificados SSH, un sueño de simplificar la gestión en empresas más grandes.
Cuando se utilizan certificados SSH para la autenticación, la clave de la CA es aquella en la que confía el servidor; como tal, cualquier clave SSH firmada por la clave de la CA será inherentemente confiable. Sabemos que esta noción puede resultar un poco confusa, así que intentemos desglosarla. Primero lo primero, repasemos la experiencia de configuración.
1) Se crea una Autoridad de Certificación (CA). En esencia, este es un par de claves SSH que simplemente firma otras claves SSH.
2) La clave pública de la CA se agrega al archivo “trusted_ca_keys.pub” del servidor.
3) Luego, el archivo “sshd_config” se modifica para considerar el archivo “trusted_ca_keys.pub” como la única fuente de verdad para las autoridades de certificación SSH.
Estos tres pasos hacen que el servidor confíe en cualquier clave SSH firmada por la clave CA, siempre que sea confiable. Ahora que se confía en la CA, todo lo que cada ingeniero debe hacer a partir de ahora es simplemente solicitar su propio certificado. Antes de profundizar en cómo hacerlo, revisemos algunas propiedades del certificado, ¿de acuerdo?
Clave pública: Esta es la clave pública del ingeniero que desea firmar.
ID de clave: Esto es simplemente una identificación que puedes darle a la llave.
Principales válidos: Estos son los principios principales de Linux que el usuario puede utilizar mediante SSH; por ejemplo, si desea obtener acceso como root, deberá agregar “root” a esta sección.
Válido después: Esta es la hora de Unix desde que es válido. El certificado no será aceptado en ningún momento antes de esto.
Válido antes: Esta es solo la fecha de vencimiento. Nos gusta establecer el nuestro en unas pocas horas, pero honestamente, esto puede establecerse tan lejos o tan cerca como lo desee su organización.
Clave de firma: Esta es la clave pública de la CA. El servidor lo utiliza para verificar que la CA es una CA confiable.
Firma: Este es el hash de todos los campos del certificado firmados por la clave privada de la autoridad certificadora.
1) Solo es necesario agregar 1 clave por servidor.
2) Las claves SSH del usuario ahora tienen una fecha de vencimiento establecida.
3) La autoridad certificadora puede proporcionar JEA al usuario cada vez que éste solicite acceso.
4) Es notablemente más fácil asociar cada clave con su respectivo propietario.
5) Si se utilizan certificados a corto plazo, las organizaciones tienen una exposición reducida al robo de claves SSH provocado por una mala gestión de claves SSH.
6) La incorporación de usuarios es mucho más rápida.
1) La computadora del usuario envía una lista de cada uno de los certificados del usuario.
2) El servidor comprueba si alguno de los certificados enviados está firmado por una CA en el archivo “trusted_ca_keys.pub”.
3) El servidor comprueba si el certificado es válido.
4) Si el servidor encuentra una coincidencia, crea un desafío.
5) La computadora del usuario completa el desafío y envía la respuesta al servidor utilizando la clave privada del certificado.
6) El servidor verifica el valor devuelto; si el servidor valida el valor devuelto, se inicia la sesión.
¿Qué logran estos pasos? Transfieren la gestión de claves desde innumerables servidores a una única CA. ¡Increíble!
Primero seleccione la máquina que será su autoridad de certificación. Recomendamos configurar una máquina cuyo único propósito sea ser una CA; esto le ayudará a proteger sus claves de firma. Si es posible, también recomendamos tener tus claves de CA protegidas por un Módulo de Seguridad de Hardware (HSM).
Una vez que haya configurado su máquina, cree su clave CA:
ssh-keygen -f ca
Ingrese una frase de contraseña segura para proteger su clave privada. Esto creará dos archivos, un archivo “ca” y un archivo “ca.pub”. NO comparta el archivo “ca” con nadie. En él se utiliza su clave privada para firmar sus certificados. Copie el ca.pub a todos sus servidores (EZSSH lo guarda en un archivo llamado: “/etc/ssh/trusted_ca_keys.pub” en los servidores). Luego ejecute la siguiente línea en el servidor que está configurando para aceptar certificados de esta CA:
echo "TrustedUserCAKeys /etc/ssh/trusted_ca_keys.pub" >> /etc/ssh/sshd_config
Esto permitirá que cualquier certificado SSH firmado por esta CA se autentique en este servidor. Ejecute el siguiente comando para reiniciar el servicio SSH en el servidor.
service ssh restart
Ahora su servidor está listo para aceptar certificados SSH.
Ahora un usuario puede crear una clave SSH usando:
ssh-keygen
Esto creará archivos id_rsa e id_rsa.pub en su carpeta .ssh. NUNCA COMPARTA su archivo “id_rsa” con nadie, este contiene su clave privada.
Copie “id_rsa.pub” a la autoridad certificadora. En la CA ejecute lo siguiente:
ssh-keygen -s ca -I YOURNAME -n root -V +1d -z YOURSERIALNUMBER id_rsa.pub
Esto creará un certificado firmado por su CA. Este certificado tendrá: su nombre como “ID de clave”, raíz como “Principal válido” y será válido por 1 día.
Copie id_rsa-cert.pub en el archivo .ssh del usuario. Ahora que tiene un certificado, podrá autenticarse en su punto final ejecutando:
"ssh root@YOURENDPOINT"
Este código es excelente para realizar pruebas; sin embargo, simplemente no escala. Cada vez que desee crear un certificado, deberá llamar a alguien para proporcionarle su clave pública. Como dijimos, esta configuración está perfectamente bien para realizar pruebas, pero al usarla en toda la organización, lo único que crea son cuellos de botella, pérdida de tiempo y frustración.
Para facilitar todo el proceso, consulte EZSSH, nuestra herramienta de administración SSH de punto final de confianza cero, donde automatizamos la creación de certificados en función de su usuario de AD. . Los principios básicos de EZSSH son no se requiere agente, niveles de seguridad mejorados y experiencia de usuario mejorada. Para obtener más información sobre cómo EZSSH puede ayudar a su organización, programe una consulta GRATUITA con uno de nuestros expertos hoy.
