Por qué usar el archivo .PEM en el proceso ssh

Ambos equipos están haciendo lo mismo

El equipo A usó ssh-keygen, para crear un par de claves privada / pública, que almacenó la parte privada en $HOME/.ssh/id_rsa y agregó la clave pública al archivo authorized_keys en el servidor. Luego, cuando se conecta al servidor, de forma predeterminada leerá la clave privada desde allí, accediendo al servidor sin tener que ingresar ninguna contraseña.

El equipo B nombró el archivo de manera diferente (probablemente usaron el parámetro -f ) y usa -i cada vez, ya que de lo contrario ssh no lo encontraría.¹

En todos los casos, ssh necesita el archivo de clave privada (puede acceder directamente al archivo privado o la clave ya está cargada en un agente ssh), solo el lugar donde se encuentra es diferente. Hay algunos otros nombres de archivo de clave que intenta de forma predeterminada si existen, y puede especificar una ubicación diferente en ~/.ssh/config (¡incluso claves diferentes para cada host si lo desea!), Por lo que no necesita ingresar explícitamente la clave nombre de archivo en cada ejecución.

(En ambos casos, la clave podría protegerse con una frase de contraseña, pero ninguno de los equipos parece estar haciendo eso)

Entonces, para responder a sus preguntas:

  

¿Qué ventajas tiene utilizar un archivo .Pem?

También estás usando el archivo clave, solo se está accediendo de forma transparente, por lo que no hay un beneficio real en lo que hacen.

  

¿Cómo es mejor que el modelo ssh que estamos usando?

mejor es un término subjetivo, pero en mi humilde opinión es mejor que indicar explícitamente que la clave es no requerida. No sería preferible no colocar la llave en la ubicación automática si quisiera usar diferentes pares de llaves y asegurarse de que una no se use automáticamente. Pero incluso entonces, para cualquier servidor al que me conecte comúnmente, configuraría ssh para elegir el archivo de clave correcto.

La configuración correcta de ssh para conectarse hace que las configuraciones complejas sean fáciles de usar, como acceder a una máquina interna que salta a través de un host de bastión intermedio, o simplemente realizar una rsync allí (que no tiene un parámetro -i directo para pasar al programa subyacente †)

† Considero que es mucho más limpio hacer rsync file server.com: que RSYNC_CONNECT_PROG='ssh -i /my/keyfile %H' rsync file server.com: ).

Tiene varios problemas en conflicto, y debe comenzar por hablar de "archivos .PEM", el formato del archivo es en gran medida irrelevante para lo que sigue.

ssh funciona con claves: claves adjuntas a usuarios y claves adjuntas a servidores. Cuando comenzó, era una criptografía asimétrica clásica, cada parte (servidores y usuarios) tiene al menos un par de claves públicas + privadas y todo esto se usa para autenticar quién se conecta a qué.

Esto funciona bien y es probablemente la clave ssh más utilizada por defecto.

Sin embargo, puede tener problemas de administración principalmente (en lugar de problemas técnicos) cuando tiene demasiados hosts o usuarios y desea un control detallado: cada servidor debe configurarse con un conjunto específico de claves de usuario, y los usuarios deben conocer una Conjunto específico de claves de servidor si quieren evitar el principio TOFU. También es posible que desee más seguridad con respecto a las claves, poder revocar el acceso fácilmente, etc.

Entonces, lo que se agregó en OpenSSH (la versión 5.4 en 2010 para disponibilidad inicial y luego la versión 5.6 para soporte completo) es la posibilidad de usar no solo claves sino también certificados X.509. Los certificados X.509 encapsulan una clave pública (donde tendría la clave privada en un archivo separado) con algunos otros metadatos, como fechas de validez u otras restricciones para usar este certificado, y son entregados por alguna Autoridad de Certificación específica.

Para servidores, usando certificados, significa que básicamente recuperas el mismo modelo que hoy en día en HTTPS. Donde puede ser más interesante es para las claves de usuario. Por ejemplo, no necesita configurar el servidor con el conjunto específico de claves de usuario permitidas para conectarse allí, solo necesita configurar el servidor para aceptar todos los certificados firmados por una CA específica, que es interna y usted controla, con algunos restricción. Luego, simplemente puede emitir a sus usuarios algunos certificados con las restricciones específicas que necesitan para conectarse a los servidores a los que necesitan conectarse.

Netflix tiene un mecanismo elaborado como el que hablaron. Sus desarrolladores tienen una forma de solicitar automáticamente nuevos certificados, de muy corta duración (en el orden de minutos, cuando la conexión SSH está abierta, no importa si el certificado caduca durante el mismo, permanece abierto), para que puedan conectarse. cualquier host.

Vea esta presentación de ellos, que puede darle algunas ideas sobre por qué los certificados pueden ser útiles: "enlace o el vídeo correspondiente: enlace

También tienen el "software de código abierto" que necesitan para esta arquitectura: enlace