relación RSA al intercambio de claves SSH

Question

relación RSA al intercambio de claves SSH

#1 de David (2 votos)

2

No entiendo completamente SSH. Esperaba que alguien pudiera arreglar mi confusión.

Cuando genera un par de claves ssh, crea cuatro archivos.

authorized_keys, id_rsa, id_rsa.pub and known_hosts

Mi confusión proviene del hecho de que RSA es una herramienta de cifrado, liberas un par de claves públicas (n, e) pero en el archivo id_rsa.pub , no hay par, es solo una cadena gigantesca, donde se divide ?

Además, ¿cómo SSH crea una verificación de contraseña del lado del servidor, RSA se usa para cifrar mensajes, cómo hace que tengan mi clave pública, combinándolos con mi clave privada creen algún tipo de confirmación de contraseña, RSA se usa para cifrar mensajes no contraseña autenticación?

cryptography ssh diffie-hellman rsa

pregunta J. Doe 09.03.2018 - 00:14

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography ssh diffie-hellman rsa

Agregar campo personalizado al certificado ¿Obtener la cantidad total, no única, de contraseñas descifradas de la salida de John the Rippers?

score 2 · Accepted Answer

known_hosts no tiene nada que ver con la autenticación de clave pública. Es una lista de los servidores a los que se conectó anteriormente y las huellas digitales de sus claves SSH para ayudar a verificar que la conexión con el servidor no se esté gestionando.

authorized_keys es un archivo almacenado en el servidor que contiene las claves públicas SSH de los usuarios autorizados para iniciar sesión en el servidor.

id_rsa es la clave privada. id_rsa.pub es la clave pública. La clave pública está codificada según el formato en RFC 4253 , pero básicamente es un blob codificado PEM que contiene el tipo de clave, la longitud y los valores n y e .

La autenticación de clave pública no implica contraseñas en absoluto. No hay ningún paso de "confirmación de contraseña" en absoluto. Cuando el cliente se conecta, ofrece las claves que tiene para el servidor. Si el servidor puede usar uno de esos para conectarse, le pide al cliente que firme los metadatos sobre la solicitud, incluidos los datos proporcionados por el cliente y el servidor. El cliente toma los datos de la solicitud, los firma con la clave privada y luego los envía de vuelta al servidor. El servidor verifica la firma del blob, lo que muestra que el cliente posee la clave privada correcta (que coincide con una de las claves públicas en authorized_keys ) y otorga acceso.