ABOUT THIS EPISODE
Te doy la bienvenida al episodio 31 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 14 de agosto de 2018.
Cuando instalamos un nuevo servidor, nos preocupamos de dejarlo actualizado, de configurar el idioma y la sincronización de hora, de instalar las aplicaciones y librerías que requiere para su uso, de hacer el hardening correspondiente para darle las condiciones básicas de seguridad, de configurar el sistema de backup y de inscribirlo en el sistema de monitoreo de nuestra infraestructura. Entre todo esto, nos tomamos muy en serio los accesos para quiénes tendrán que hacer login: con qué usuario ingresarán, si ese usuario tendrá permisos en el sudoers y recolectamos e inscribimos con mucho cuidado los certificados públicos SSH en el authorized_keys para que ingresen.
Ahora, te pregunto una cosa ¿no sientes que la administración de todos estos certificados ssh es algo frustrante?
Te cuento lo que me suele pasar a mi: a medida que va pasando el tiempo los servidores empiezan a tener certificados que no se sabe bien a quién pertenecen, a veces de algún desarrollador que necesitó entrar para una ayuda puntual, a veces de alguna proveedor que necesitó algún acceso.
También se vuelve bastante difícil distribuir los certificados para los nuevos administradores y quitar aquellos de los que no están más afectados al servidor y ya no deberían tener acceso, algunas veces puedo manejar esto con Ansible, algunas veces es una tarea manual.
Como que siento que en la carrera de mantener y administrar los accesos con certificados SSH estoy atrás.
Pero existe una luz sobre este problema, una solución bastante simple pues desde la versión de OpenSSH 5.4 es posible utilizar certificados tanto para servidores, como para usuarios, basados en la confianza dada por una Autoridad de Certificación y de esto, vamos a conversar en esta edición de deployandome.
Add support for certificate authentication of users and hosts
using a new, minimal OpenSSH certificate format (not X.509).
Certificates contain a public key, identity information and
some validity constraints and are signed with a standard SSH
public key using ssh-keygen(1). CA keys may be marked as
trusted in authorized_key or via a TrustedUserCAKeys option
in sshd_config(5) (for user authentication), or in known_hosts
(for host authentication).
No es la primera vez que en deployandome tratamos el tema de OpenSSH: en la edicione 4 conversamos sobre sshuttle para armar VPN con SSH, en la edición 5 de sshfs para montar por SSH filesystems de servidores remotos, o por ejemplo, en la edicion 20 de MOSH para mantener un shell permanente y performante validando por SSH.
Pero más allá de esto, explicar el funcionamiento de la validación que hace OpenSSH con los certificados siempre me ha resultado un desafío interesante; cuando lo hago en el marco de los cursos que dicto en la Universidad termino con unos gráficos en el pizarrón, unas cuantas flechas, recuadros y hasta colores que me ayudan en la explicación.
Ahora voy a tratar de explicártelo tipo cuento, acercándote a los conceptos y, si necesitas profundizar, siempre puedes recurrir al blog deployando.me donde dejo comandos y referencias a documentación adicional.
Para una conexión por SSH tenemos básicamente dos tipos de validación donde intervienen certificados
Primero una validación del host al que nos estamos conectando, donde nos atiende un servidor OpenSSH y nos envía un paquete firmado que verificamos con el certificado público que tenemos guardado en el archivo local known_hosts, que es el llavero donde tenemos los certificados de los hosts en los cuales confiamos. Si no tenemos el certificado público nos pregunta si queremos incorporar el certificado a nuestro llavero y contestamos el famoso ye
