Tengo problemas para comprender cómo funciona realmente ssh. Sé que usa una criptografía de clave pública para cifrar mensajes. Sin embargo, puedo conectarme a un servidor sin generar primero un par de claves pública / privada para mí. Revisé mi carpeta .ssh y no hay un archivo .pub allí, así que asumo que no tengo una clave pública que el servidor tenga en cuenta. Entonces, ¿cómo puede el servidor enviarme un mensaje cifrado si no tengo una clave pública en primer lugar?
Esas son en realidad dos cosas diferentes. La pareja de claves pública / privada de la que habla es para la autenticación .
Cuando se conecta a un servidor ssh, su cliente y el servidor negocian las claves que utilizan para el cifrado de su comunicación. Algún algoritmo derivado del algo de intercambio de claves Diffie-Hellmann . El mismo método se utiliza cuando accede a una página con su navegador a través del protocolo https.
Si está interesado en el funcionamiento interno del protocolo ssh, puede consultar aquí . Está abierto;)
edit : Pero estoy de acuerdo con Dennis, el foro de criptografía es el mejor lugar para esto.
Como describe @klaustopher, el túnel SSH utiliza un intercambio de claves Diffie-Hellman, para establecer un secreto compartido entre el cliente y el servidor; este secreto compartido se usa con criptografía simétrica para cifrar y verificar la integridad de todos los datos intercambiados posteriormente.
Como tal, el criptografía simétrica DH + está bien, pero solo cumple la mitad del trabajo. Cuando se ha ejecutado el protocolo DH, el cliente y el servidor saben que ahora tienen un túnel seguro con ... alguien. Pero ellos no saben quién . Solo saben que esta será la misma entidad durante toda la vida útil de la conexión. Por lo tanto, esto es vulnerable a los atacantes activos que se hacen pasar por el cliente, el servidor o ambos. El famoso ataque Man-in-the-Middle es un caso de doble personificación (el atacante actúa como servidor falso cuando habla con el cliente, y como cliente falso cuando habla con el servidor).
Para hacer que un túnel completamente seguro sea seguro para transmitir datos confidenciales y comandos confidenciales, el cliente y el servidor deben autenticarse mutuamente. En los primeros pasos del protocolo, el servidor firma lo que envía (su mitad del protocolo Diffie-Hellman); el cliente verifica esa firma con respecto a la clave pública del servidor conocido (la que el cliente almacena en .ssh/known_hosts ). Una vez que se ha verificado la firma, el cliente sabe que está realizando el intercambio de claves DH con el servidor original, no un atacante que se hace pasar por el servidor deseado. Esto significa que el cliente puede enviar datos confidenciales de forma segura a través del túnel. En particular, una vez que se ha hecho el DH, los primeros intercambios son los siguientes:
Gracias a la autenticación del servidor por parte del cliente (a través del algoritmo de verificación de firma), el cliente sabe que puede enviar su contraseña de forma segura en el túnel.
El protocolo SSH también admite la autenticación de clientes basada en firmas. El DH y la firma por el servidor todavía se realizan como anteriormente. Pero el protocolo entonces va así:
.ssh/authorized_keys contiene una clave pública que coincide con la identificación que envió, y su firma en mi desafío se verifica correctamente con respecto a esa clave pública. Bienvenido, Bob. Más o menos lo mismo sucede con HTTPS. Hay muchas diferencias locales, por ej. el cliente HTTPS reconoce la clave pública del servidor validando un certificado en lugar de recordarlo de una visita anterior; y la contraseña puede tomar la forma de páginas web reales; pero la esencia del intercambio es la misma: el cliente se asegura de que habla con el servidor correcto al verificar su clave pública, y luego el servidor se asegura de que habla con el cliente correcto (si el servidor está realmente interesado en saber < em> who es el cliente) ejecutando algún tipo de protocolo de autenticación dentro de el túnel.
Lea otras preguntas en las etiquetas authentication cryptography encryption ssh