¿Cómo funcionan las claves SSH? [duplicar]

  

Básicamente, ¿qué lo 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á cifrado a menos que use cifrados rotos), pero en teoría puede ser interceptado por Man In the middle o un usuario (super) malicioso en el servidor remoto.

  

¿Y cómo juega la clave pública en las cosas?

Este es el punto de la criptografía asimétrica. La clave privada crea la firma y el público puede verificar que la firma fue realizada por la clave pública respectiva. Envía la clave pública y la firma de los datos ofrecidos por el servidor y esto es suficiente para que el servidor le permita el acceso (si la clave pública coincide con la de authorized_keys ).

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 utilizar la clave pública de un cliente. Las claves asimétricas generalmente son más difíciles de romper porque no están sujetas a que los usuarios creen contraseñas incorrectas. Por este motivo, se prefiere la autenticación basada en clave pública. Puede incluir en la lista blanca las claves públicas específicas para su usuario (e IP) para que nadie pueda iniciar sesión con su nombre de usuario y desde cualquier computadora. Esta lista blanca está contenida en /home/<user>/.ssh/authorized_keys .

Fundamentos de SSH:

1. El servidor presenta su clave pública RSA al cliente. El cliente verifica manualmente que confía en esta clave antes de continuar.

2. SSH usa Diffie Hellman para establecer un valor secreto compartido.

3. El secreto compartido junto con una gran cantidad de datos de intercambio de claves está en hash juntos y firmados con la clave privada del servidor.

4. El cliente puede verificar esta firma usando el servidor previamente clave pública de confianza.

5. Ambos lados ahora tienen toda la información necesaria para generar la sesión llaves.

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 encriptado, el protocolo SSH comienza la autenticación del cliente en función de los parámetros que le hayas dado. Todo esto se realiza de forma segura a través del canal encriptado.

Déjame proporcionar una imagen de alto nivel. Claramente, usted comprende la necesidad de comunicaciones seguras, ya sea SSH o HTTPS. Las comunicaciones seguras significan que el canal está cifrado.

En términos generales, todos los algoritmos de cifrado se dividen en una de dos categorías:

• cifrado simétrico. Una llave. La misma clave se utiliza para cifrar y descifrar. Rápido. P.ej. AES.
• Encriptación asimétrica. Dos llaves. Cualquiera de los dos 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 construya únicamente en un algoritmo de cifrado simétrico sin encontrar una manera de compartir primero su clave / contraseña.

Aquí es donde entran los algoritmos asimétricos, pero son considerablemente más lentos que los 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 de cifrado / contraseña simétrica. Una vez hecho esto, ahora puede utilizar el cifrado simétrico para las comunicaciones.

Una de las dos claves para el cifrado asimétrico se denomina clave pública y la otra clave privada. La clave pública puede distribuirse 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 realmente hace SSH. 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 la clave simétrica juntas durante el intercambio de claves, lo que es una buena característica de seguridad. Consulte "Diffie-Hellman Key Exchange" 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 en las que confías. Para confiar en una clave pública, debe estar firmada digitalmente. Una clave pública firmada también se conoce como certificado.

Esperamos que esto aclare las preguntas sobre las contraseñas largas y las claves públicas, y que tenga suficiente información para que puedas profundizar de una manera más significativa.