Cómo asegurar la conexión SFTP en ambos sentidos

Cómo asegurar la conexión SFTP en ambos sentidos

Quiero configurar una conexión SFTP entre mi computadora y un servidor.

Generé un par de claves en mi computadora y escribí mi clave pública en el archivo "authorized_keys" en el servidor. Estoy seguro de que funciona porque cuando intento conectarme desde una computadora que no tiene mi clave privada (lo sé, se supone que nadie más debe tenerla), se solicita una contraseña.

De acuerdo aesta imagen, mi servidor es Bob y mi computadora es Alice. Cuando el servidor envía un mensaje, usa mi clave pública para cifrarlo y yo uso mi clave privada para descifrarlo. Pero si envío un mensaje al servidor, no está cifrado, ¿verdad? Si es así, ¿cómo se cifra?

Por lo que entendí sobre la criptografía asimétrica, si quiero cifrar los mensajes que envío, tengo que generar un par de claves en el servidor y poner su clave pública en el archivo "claves_autorizadas" de mi computadora, ¿verdad?

Cómo puedoverificar¿Que la conexión es segura en ambos sentidos (envío y recepción)?

¡Gracias!

Respuesta1

Hay dos cosas principales que suceden en las conexiones SSH:

Autenticación y cifrado del servidor

El servidor te envía su clave pública y debes confiar en ella. Podrías obtenerlo manualmente antes de eso y en un entorno de seguridad ideal nunca te conectarías a un servidor SSH ANTES de saber que su clave pública es correcta. Para eso sirven las CA, firman la clave pública de un servidor. En la mayoría de los entornos SSH, simplemente acepta la clave pública del servidor como cliente. Esta es la pregunta inicial "¿quieres confiar en este servidor y agregarlo a tu lista?".La clave pública del servidor se almacena en .ssh/known_hosts en el cliente en sistemas Linux..

El cifrado real de la conexión no es asimétrico. Este es un gran error que mucha gente tiene sobre el cifrado de clave pública/privada. Sería MUY lento. Lo que realmente sucede es que el servidor y el cliente generan un secreto compartido (también conocido como contraseña larga) que escifrado simétricopara esta única sesión. El cliente y el servidor utilizan cifrado asimétrico hasta que acuerdan un secreto compartido. Después de eso, cambian al cifrado simétrico con este secreto compartido como clave.

Este tipo de cifrado es el más común y se llamacifrado híbrido, aunque casi todo el mundo lo llama (erróneamente) cifrado asimétrico.

Un ejemplo de cifrado asimétrico puro "real" es el cifrado de correo con PGP, porque TODOS los mensajes se cifran de forma asimétrica.

Además: el secreto compartido no se almacena permanentemente, cada nueva sesión se negocia un nuevo secreto compartido.

Autenticación del cliente

Esto es algo completamente diferente, esto es lo que puede ser una autenticación basada en contraseña y/o clave. La clave pública del cliente (ubicada en ~/.ssh/id_rsa.pub) debe estar presente en el archivo de claves_autorizadas del servidor (por ejemplo, para raíz: /root/.ssh/claves_autorizadas). Antes de que ssh-copy-idexistiera la gente haría algo como

    cat ~/.ssh/id_rsa.pub | ssh root@server "cat >>  ~/.ssh/authorized_keys"

para agregar su clave a los servidores autorizados_keys.

El certificado de cliente NO se utiliza para cifrado, solo para autenticación.

Edición IMPORTANTE:Se hizo la publicación más clara ssh-copy-idpara evitar malentendidos.

A partir de ahora, ssh-copy-ides la mejor forma de agregar la clave pública de un cliente a un servidor. Acabo de publicar el catmétodo para mostrar qué archivos se manipulan en ambos lados para mostrar la conexión entre las claves públicas y privadas y cómo se almacenan.

Al utilizar cat existe el riesgo de olvidar un ">", por ejemplo, lo queSobrescribirsu archivo de claves_autorizadas (en Linux ">>" significa agregar, ">" significa sobrescribir). Sea responsable al manipular archivos de configuración directamente. Gracias @Rallph por señalarlo.

Respuesta2

El servidor tiene su propio par de claves. Cuando se conecta por primera vez a un servidor SSH, su cliente SSH/SFTP debería avisarle, si confía en la clave de host del servidor (= clave pública).

Sólo después de verificar cuidadosamente que se trata de una clave pública legítima del servidor, su conexión será segura. Vermiartículo¿Dónde obtengo la huella digital de la clave del host SSH para autorizar el servidor?

También tenga en cuenta que ni su par de claves ni el par de claves del servidor se utilizan realmente para cifrar los datos. Eso es mucho más complicado.

Ver también:

información relacionada