¿Sabía que la mayoría de los servidores SSH tienen alrededor de 200 llaves SSH y el 90 % de ellas no se utilizan? Bueno, si has leído nuestro blog que describe los problemas con el uso de llaves SSH, entonces sabes que las llaves son * Así* la temporada pasada, y que los certificados SSH son el camino a seguir cuando se trata de cumplir con los más altos estándares de ciberseguridad/autenticación. Puede consultar nuestro blog que detalla cómo funcionan los certificados SSH para obtener una descripción más detallada en ese frente, pero la esencia de por qué son tan confiables es el siguiente: cuando emplea certificados SSH para sus necesidades de autenticación, la llave que utiliza la CA es la llave en la que confía su servidor, lo que indica que cualquier llave SSH que firme la CA es inherentemente confiable. Esto elimina la necesidad de agregar y eliminar manualmente llaves SSH de sus servidores.
Antes de comenzar y crear el primer certificado SSH, hablemos de cómo funcionan los certificados SSH. En términos más simples, un certificado SSH es la parte pública de una llave SSH e información de metadatos adicionales firmada por otra llave SSH (la autoridad certificadora). Probablemente estés pensando, “esto suena mucho a Certificados X509” ¡y estás en lo cierto! Es esencialmente el mismo concepto. Dicho esto, los certificados SSH son más simples y tienen menos campos, lo que facilita su lectura para los servidores SSH. Esto le permite usarlos en casi cualquier punto final SSH (incluidos dispositivos IoT, dispositivos de red y más).
Como se mencionó anteriormente, los certificados SSH solo tienen los campos necesarios para identificar al usuario y habilitar la autenticación en el punto final. Estos campos son:
llave pública: esta es la llave pública del ingeniero que desea firmar. Esto permite que la máquina valide la solicitud de inicio de sesión.
ID de llave: 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: este es el tiempo 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.
Llave de firma: Esta es la llave 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 llave privada de la autoridad certificadora.
Ahora que conocemos las partes del certificado SSH, podemos crear un certificado SSH. Primero, debemos crear nuestra Autoridad de Certificación SSH. Recomendamos configurar una máquina con el único propósito de ser una CA. Esto le ayudará a proteger sus llaves de firma. Si es posible, también recomendamos tener tus llaves de CA protegidas por un Módulo de Seguridad de Hardware (HSM).
Una vez que haya configurado su máquina, cree su llave CA:
ssh-keygen -f ca
Ingrese una frase de contraseña segura para proteger su llave privada. Esto creará dos archivos, un archivo “ca” y un archivo “ca.pub”. NO comparta el archivo “ca” con nadie. Esa es tu llave privada.
Ahora se ha creado su Autoridad de Certificación SSH. Ahora tenemos que agregar la CA a nuestros servidores, para que acepten certificados SSH firmados por esta CA.
Ahora que tenemos el certificado SSH, lo copiaremos en el punto final SSH en el que desea autenticarse. Asumiré que lo copió en un archivo llamado “/etc/ssh/trusted_ca_keys.pub” para que ahora podamos agregarlo a nuestro sshd_config para confiar en los certificados firmados con la llave guardada en “/etc/ssh/trusted_ca_keys.pub”. Hacemos esto ejecutando el siguiente comando:
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. Para que estos cambios surtan efecto, ejecute el siguiente comando para reiniciar el servicio ssh en el servidor.
service ssh restart
Ahora este servidor utilizará el principal del certificado para validar que es un usuario válido y autenticará a los usuarios con llaves firmadas por nuestra CA. A continuación, crearemos nuestro primer certificado SSH.
Ahora, en tu portátil creamos la llave SSH que usaremos para el primer certificado. Hacemos esto simplemente creando una llave SSH normal.
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 llave privada.
Copie “id_rsa.pub” a la CA. En la CA ejecute lo siguiente:
ssh-keygen -s ca -I YourUserName -n root -V +1d -z YOURSERIALNUMBER id_rsa.pub
Esto creará un certificado firmado por su CA. Este certificado tendrá: su nombre de usuario como “ID de llave”, raíz como “Principal válido” y será válido por 1 día.
Copie id_rsa-cert.pub en la carpeta .ssh del usuario.
También puedes ver los valores del certificado tú mismo ejecutando:
ssh-keygen –Lf id_rsa-cert.pub
Dado que en este caso creamos la llave SSH y agregamos el certificado SSH a la carpeta SSH, su agente SSH sabrá ofrecer las llaves en esa carpeta. Lo que significa que un comando SSH simple como este funcionará:
"ssh root@YOURENDPOINT"
Sin embargo, si no almacenó las llaves y los certificados en esa carpeta, puede especificar el uso de su llave; puede pasar -i con la ubicación de la llave, por ejemplo:
"ssh -i myKeyLocation root@YOURENDPOINT"
Y tan simple como eso, creamos su primer certificado SSH y lo autenticamos en su punto final. Si bien esto es excelente para una prueba de concepto, la emisión manual de certificados para los usuarios no se adapta a una organización. ¡Es por eso que hemos creado EZSSH! Esta autoridad de certificación SSH abstrae la emisión del certificado. EZSSH utiliza su identidad y grupos de AAD (Azure Active Directory) existentes e incluso Azure RBAC (control de acceso basado en roles) para máquinas virtuales alojadas en Azure (máquinas virtuales) y emite un certificado SSH a corto plazo al usuario para permitir el acceso justo a tiempo a sus servidores. . Vea el vídeo a continuación para ver lo fácil que es SSH usando EZSSH:
