Esta pregunta ya tiene respuestas aquí :
Comentarios
Responder
Básicamente, ¿qué la hace mejor que una contraseña realmente larga?
No se transfieren al servidor (ya que incluso la contraseña muy larga debe transferirse). No es inseguro en el caso ssh (el canal está encriptado a menos que uses cifrados rotos), pero en teoría puede ser interceptado por Man In the middle o por un (super) usuario malicioso el servidor remoto.
¿Y cómo influye la clave pública en las cosas?
Este es el punto de la criptografía asimétrica. La clave privada crea la firma y la pública puede verificar que la firma fue realizada por la clave pública respectiva. Envías la clave pública y la firma de los datos que ofrece el servidor y esto es suficiente para que el servidor te permita el acceso (si la clave pública coincide con la de authorized_keys).
Comentarios
Responder
No estoy seguro de qué estás comparando SSH con la «contraseña muy larga». SSH proporciona un medio seguro para enviar su nombre de usuario y contraseña a un servidor remoto. O puede usar la clave pública de un cliente. Las claves asimétricas son generalmente más difíciles de romper porque no están sujetas a que los usuarios creen contraseñas incorrectas. Por ese motivo, se prefiere la autenticación basada en clave pública. Puede hacer una lista blanca de claves públicas específicas para su usuario (e IP) para que no cualquiera pueda iniciar sesión con su nombre de usuario y desde cualquier computadora. Esta lista blanca está contenida en /home/<user>/.ssh/authorized_keys.
Conceptos básicos de SSH:
-
El servidor presenta su clave pública RSA a el cliente. El cliente verifica manualmente que confía en esta clave antes de continuar.
-
SSH usa Diffie Hellman para establecer un valor secreto compartido.
-
El secreto compartido junto con una gran cantidad de datos de intercambio de claves se combinan y se firman utilizando la clave privada del servidor.
-
El cliente puede verificar esta firma utilizando previamente las del servidor. clave pública confiable.
-
Ambos lados ahora tienen toda la información necesaria para generar claves de sesión.
De la sección 7.2 de RFC4253
7.2. Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we"ll call it HASH. Encryption keys MUST be computed as HASH, of a known value and K, as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data. "A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. As many bytes as needed are taken from the beginning of the hash value. If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: K1 = HASH(K || H || X || session_id) (X is e.g., "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH.
Una vez que se establece el canal cifrado, el protocolo SSH comienza la autenticación del cliente basada en según los parámetros que le haya proporcionado. Todo esto se realiza de forma segura a través del canal cifrado.
Respuesta
Permítanme brindarles una imagen de alto nivel. Claramente, comprende la necesidad de comunicaciones seguras, ya sea SSH o HTTPS. Las comunicaciones seguras significan que el canal está encriptado.
En términos generales, todos los algoritmos de encriptación se dividen en una de dos categorías:
- Encriptación simétrica. Una llave. La misma clave se utiliza para cifrar y descifrar. Rápido. P.ej. AES.
- Cifrado asimétrico. Dos llaves. Cualquiera puede usarse para cifrar, pero solo el otro puede descifrar. Mucho más lento que los algoritmos simétricos. P.ej. RSA.
El cifrado simétrico es rápido y, por lo tanto, adecuado para comunicaciones que involucran una gran cantidad de datos entre dos partes. Utiliza la misma clave para el cifrado y el descifrado; esta clave es análoga a su concepto de una contraseña muy larga. Problema: ¿cómo comparte su clave / contraseña en primer lugar? Resulta que no puede usar un canal seguro que se basa únicamente en un algoritmo de cifrado simétrico sin descubrir una manera de compartir primero su clave / contraseña.
Aquí es donde entran en juego los algoritmos asimétricos, pero son considerablemente más lentos que algoritmos simétricos. No es práctico transmitir grandes cantidades de datos, pero está bien si transmite o intercambia algo pequeño como una clave / contraseña de cifrado simétrico. Una vez hecho esto, puede usar el cifrado simétrico para las comunicaciones.
Una de las dos claves para el cifrado asimétrico se designa como clave pública y la otra como clave privada. La clave pública se puede distribuir a todos, pero la clave privada debe mantenerse en secreto.
You (has pub) Server (has prv + pub) asym-encrypt(pub, sym-key/pwd) ----> asym-decrypt(prv, encrypted-data) => sym-key/pwd
pub = clave pública, prv = clave privada
En cualquier caso, esta explicación es una simplificación de lo que SSH realmente hace. Otras dos cosas que vale la pena destacar:
-
Diffie Hellman es el típico algoritmo asimétrico de intercambio de claves. Con Diffie Hellman no es necesario crear una clave simétrica . Ambas partes crean juntas la clave simétrica durante el intercambio de claves, lo cual es una buena característica de seguridad. Consulta " Intercambio de claves Diffie-Hellman " en inglés sencillo .
-
En mi explicación asumí que encontraste la clave pública del servidor y que confías en que es la correcta. Pero realmente debes tener cuidado con las claves públicas que confianza. Para confiar en una clave pública, debe estar firmada digitalmente. Una clave pública firmada también se conoce como certificado.
Con suerte, esto aclarará las preguntas sobre la contraseña larga y claves públicas, y tiene suficiente información para que pueda profundizar de una manera más significativa.