¿Cómo se asegura el cliente SSH de que el servidor SSH tenga la clave privada, que es el par de la clave pública en el archivo "known_hosts" del cliente?

El Protocolo de la capa de transporte de Secure Shell (SSH) (RFC 4253) describe cómo se realiza la autenticación del servidor. De acuerdo con la sección 7 hay una autenticación de servidor implícita y explícita. La autenticación implícita requiere un secreto compartido entre el cliente. La autenticación explícita significa que los "mensajes de intercambio de claves incluyen una firma u otra prueba de la autenticidad del servidor" . Este es el tipo de autenticación de servidor que usualmente se usa, es decir, donde el servidor tiene un par de claves, el cliente conoce la clave pública y quiere verificar que el objetivo de la conexión conoce la clave privada correspondiente.

La forma en que se incluye la autenticación explícita en el intercambio de claves Diffie-Hellman se describe en la sección 8. Esencialmente, el servidor firma algunos datos del cliente que usa la clave privada del servidor para demostrar la propiedad de la clave y el cliente valida esta firma usando el código Llave pública. Estos datos proporcionados por el cliente incluyen datos aleatorios, por lo que es imposible reproducir una firma anterior. Para obtener información más detallada, consulte el RFC en sí mismo .

No creo que esta comprobación sea la autenticación del cliente SSH, a lo que se refiere como si fuera la memoria caché de las claves del servidor en el cliente SSH. Esto sirve para identificar el servidor, pero no es autenticación

Hay dos escenarios de autenticación para SSH (que yo sepa), en ambos casos es el cliente el que está autenticado, no el servidor:

1) (predeterminado) autenticación de contraseña simple, donde el servidor reta al cliente por una contraseña. No hay comprobación por parte del cliente en ese caso.

2) Uso de claves SSH: esto implica generar una clave privada en la máquina cliente e importar la clave pública correspondiente al servidor. En este caso, algo similar sucede con lo que está describiendo, pero el cliente está utilizando su propia clave privada para cifrar el mensaje del servidor. El servidor luego está verificando este mensaje cifrado contra la clave pública del cliente. Se ve como más seguro y más fácil de administrar que una contraseña simple, siempre que la clave privada se mantenga segura

Aquí hay un buen desglose del proceso de autenticación de clave SSH por Digital Ocean

Siendo frustrado por DigitalOcean por este tema también, propongo esta respuesta. La referencia es la sección 8 de RFC4253 que afirma, durante el intercambio de claves Diffie-Hellman:

  

Primero, el cliente envía lo siguiente:

  byte      SSH_MSG_KEXDH_INIT
  mpint     e

     

El servidor responde con lo siguiente:

  byte      SSH_MSG_KEXDH_REPLY
  string    server public host key and certificates (K_S)
  mpint     f
  string    signature of H

Básicamente, durante intercambio / generación de claves Diffie-Hellman , el cliente crea la clave "e" de su clave secreta "x"; El servidor hará lo mismo con "f" de "y". Con "x" y "f" (cliente) o "y" y "e" (servidor), la clave secreta de encriptación "K" se calcula en ambos lados (te dejo ver la magia Diffie-Hellman).

Luego viene el truco :) Se realiza un gran cálculo en ambos lados: "H". Que es un hash de una cadena larga que incluye muchas cosas como e, f, nombre del servidor "V_S", nombre del cliente "V_C", contenido de mensajes anteriores ("SSH_MSG_KEXINIT" de client / server="I_C" / "I_S") , la clave del servidor público "K_S" y, por último, la clave secreta K:

  

H = hash (V_C || V_S || I_C || I_S || K_S || e || f || K)

H no se proporciona explícitamente al cliente ya que conoce toda esta información y, por lo tanto, puede calcularla también; sino que, más bien, el servidor proporciona la firma de H, calculada con la clave privada del servidor. El cliente puede verificar esta firma gracias a su propio cálculo de H y la clave pública K_S para autenticar el servidor.

El punto principal en mi humilde opinión es mezclar, al menos, K (secreto) y firma: ¡ningún MitM puede enmascarar un mensaje de este tipo!

Esto parece ser una respuesta relevante a su pregunta: Verificación de la huella digital de SSH de un servidor público

En resumen, el servidor SSH tiene una clave pública y privada que se usa al establecer una conexión desde el cliente SSH. El servidor proporcionará una copia de su clave pública al cliente donde se presenta al usuario para su verificación. El usuario es responsable de validar esa clave con el administrador del servidor y luego aceptar la clave.

Una vez aceptado, el usuario solo volverá a ver eso si la clave cambia. Cuando la clave cambia, puede tratarse de una nueva clave realizada en el servidor por el administrador o mediante un ataque de estilo MITM; tendría que volver a verificar la clave con el administrador para ver cuál es cuál.

No hay un 'desafío', ya que creo que lo estás intentando decir, ya que así es como Public-Key La criptografía funciona.

EDITAR: Un servidor SSH generará automáticamente sus claves de host durante la instalación mediante el uso de la aplicación ssh-keygen . Esto normalmente crea una clave RSA, DSA, ecdsa o ed25519, o alguna variación de las mismas (según la configuración).

Un cliente que se conecta al servidor usará ssh-keyscan para verificar la huella digital del servidor y se lo presentará a usted como usuario para su verificación. Cuando acepta esa clave, la escribe en el archivo ~/.ssh/known_hosts para recordarla. Cada vez que su cliente ssh se conecta a ese servidor, lee la huella digital, la verifica en el archivo known_hosts y se asegura de que no haya cambiado. Si lo hace, a usted, el usuario, se le muestra una advertencia de que la clave ha cambiado y la conexión se ha detenido. Debe eliminar o alterar manualmente la clave para poder conectarse de nuevo.

$ ssh-keyscan some.remote.server
some.remote.server ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA8BPNr+Q8cQfU95jfJKIfAH+z0+q03QDeFH1ndeTC3Zf0EDjZOg1OXs+Xiwjgrkq+vcNIA5DPaux3aStrcSa5o1AjgBNKN4rMyaLMW1c5LUnSic2oE7YTGvO1AHL55+Z4rCiEbDHeK2LXwhZifNvqkxf44pKrIe8kCvt89dkRsCria4n5EedGazKxO0mvbHM9JSpg03CiD4B+/afOrZqCJrf5dYcDCmeiBPSn9vjiZzAl2NYj05GVSqoe8KeFQV9n4c4LtWfzSDshvLlypuSfylzhL3euWG6JP8G6HnBohSiSQFk/Y0VFX/4wYshKjN3px0ugYUrucXXv8Sznv6n1Dw==

Si abrieras el archivo known_hosts en mi sistema, verías esta entrada exacta allí.

EDIT 2:

Al leer los comentarios, parece que estás atascado en este bit de huella digital. La huella digital es la parte pública de criptografía de clave pública. Realmente deberías leer más sobre esto ya que te vinculé antes para comprender completamente este concepto. En Crypto de clave pública, una clave privada y una clave pública se crean matemáticamente simultáneamente. Este par de claves tiene una habilidad especial en el sentido de que cualquier cosa encriptada por la clave privada puede SOLAMENTE ser descifrada por la clave pública y cualquier cosa encriptada por la clave pública puede SOLAMENTE ser descifrada por el Llave privada. Esto es cyrpto asimétrico, NO criptografía simétrica (usando una clave para cifrar / descifrar).

También debe comprender cómo funciona la firma para comprender el uso del cifrado de clave pública. Si escribo un mensaje en texto sin formato y se lo envío, usted no sabe que lo envié. Si, por el contrario, escribo un mensaje de texto simple y en la parte inferior agrego un blob cifrado que contiene un hash del mensaje y se cifró con mi clave privada, entonces mi clave pública puede usarse para descifrar el blob, el mensaje de texto simple original puede se hash y se compara con el hash que incluí en el blob encriptado.

Este mismo concepto se aplica aquí con SSH. Dado que solo la clave privada utilizada en el servidor es capaz de trabajar con la clave pública que tiene su cliente, puede probar matemáticamente que son la misma máquina. Como mencioné en mi comentario, es casi imposible generar dos claves privadas que sean una coincidencia exacta, proporcionando así una huella dactilar duplicada. Si pudiera generar una clave privada que fuera exactamente igual a la clave privada de otro servidor, entonces sí, tendría la misma huella digital que cualquier otro servidor. Considere esto como imposible hoy.

He leído partes del RFC4253 como sugirió Steffen Ullrich. La siguiente es una descripción muy incompleta, pero lo que entiendo es:

1. El cliente y el servidor obtienen una serie de secretos compartidos como resultado del intercambio de claves.
2. El servidor firma estos secretos compartidos con su clave privada y los envía al cliente.
3. El cliente descifra esto usando la clave pública del servidor. Si el resultado coincide con lo que se describe en el RFC4253, entonces el servidor se autentica.

Por un momento, pensé: "Espere, ¿por qué necesitamos un mecanismo de autenticación explícito? Dado que el cliente está utilizando la clave pública del servidor para cifrar las cosas que envió al servidor, si el servidor es falso, el servidor no funcionará". No se puede descifrar lo que envía el cliente. Dado que el servidor no entendería lo que dijo el cliente, el servidor no podrá producir una respuesta significativa. Por lo tanto, el cliente sabrá que el servidor es falso ya que El servidor enviará una respuesta sin sentido ".

Bueno, el párrafo anterior es totalmente incorrecto. Debido a que el cliente y el servidor utilizan cifrado de clave simétrica para comunicarse después del intercambio de claves. Por lo tanto, las claves asimétricas del servidor (y potencialmente del cliente) se utilizan solo con fines de autenticación. No con fines de comunicación.