Como funcionam as chaves SSH? [duplicar]

Basicamente, o que a torna melhor do que uma senha realmente longa?

Eles não são transferidos para o servidor (até mesmo a senha muito longa deve ser transferida). Não é inseguro no caso ssh (o canal é criptografado a menos que você use cifras quebradas), mas em teoria pode ser interceptado por Man In the middle ou mal-intencionado (super) usuário em o servidor remoto.

E como a chave pública interfere nas coisas?

Este é o ponto da criptografia assimétrica. A chave privada cria assinatura e o público pode verificar se a assinatura foi feita pela respectiva chave pública. Você envia a chave pública e a assinatura dos dados oferecidos pelo servidor e isso é suficiente para o servidor permitir o acesso (se a chave pública corresponder àquela em authorized_keys).

Comentários

• Portanto, ele envia a chave pública, se corresponder, os dados que retornam são criptografados com essa chave pública, que a chave privada pode então descriptografar ? E vice-versa com a criptografia privada e a descriptografia pública?
• criptografada com aquela chave pública, que a chave privada pode então descriptografar – assinada com a chave privada, que a chave pública pode verifique.
• O que significa " assinado "? O que impede algo descriptografando algo, mesmo que a assinatura não seja confirmada?
• @amflare: en.wikipedia.org/wiki/Digital_signature Se houver alguma coisa, então o código do próprio ' possível descriptografador.
• Certo, eu entendo. Daí minha (aparentemente falha) suposição de que as chaves permitiam a criptografia e descriptografia. Mas parece que se eu fosse uma parte mal-intencionada, poderia interceptar os dados e ignorar a autenticidade da assinatura e tentar descriptografá-la de qualquer maneira. Tive a impressão de que as chaves serviam também como meio de impedir que terceiros fizessem isso.

Não tenho certeza do que você está comparando SSH com a “senha muito longa”. O SSH fornece um meio seguro de enviar seu login de usuário e senha para um servidor remoto. Ou você pode usar a chave pública de um cliente. Chaves assimétricas são geralmente mais difíceis de quebrar porque não estão sujeitas à criação de senhas incorretas pelos usuários. A autenticação baseada em chave pública é preferida por esse motivo. Você pode colocar na lista branca chaves públicas específicas para o seu usuário (e IP) para que nem qualquer pessoa possa fazer o login com o seu nome de usuário e de qualquer computador. Esta lista branca está contida em /home/<user>/.ssh/authorized_keys.

Noções básicas de SSH:

1. O servidor apresenta sua chave pública RSA para o cliente. O cliente verifica manualmente se confia nessa chave antes de continuar.

2. O SSH usa Diffie Hellman para estabelecer um valor de segredo compartilhado.

3. O segredo compartilhado junto com muitos dados de troca de chave são misturados e assinados usando a chave privada do servidor.

4. O cliente pode verificar esta assinatura usando o servidor anteriormente chave pública confiável.

5. Ambos os lados agora têm todas as informações necessárias para gerar chaves de sessão.

Da seção 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. 

Assim que o canal criptografado é estabelecido, o protocolo SSH começa a autenticação do cliente com base de acordo com os parâmetros que você forneceu. Tudo isso é executado com segurança por meio do canal criptografado.

Deixe-me fornecer uma imagem de alto nível. Claramente, você entende a necessidade de comunicações seguras, seja SSH ou HTTPS. Comunicações seguras significam que o canal está criptografado.

De modo geral, todos os algoritmos de criptografia se enquadram em uma de duas categorias:

• Criptografia simétrica. Uma chave. A mesma chave é usada para criptografar e descriptografar. Rápido. Por exemplo. AES.
• Criptografia assimétrica. Duas chaves. Qualquer um pode ser usado para criptografar, mas apenas o outro pode descriptografar. Muito mais lento do que algoritmos simétricos. Por exemplo. RSA.

A criptografia simétrica é rápida e, portanto, adequada para comunicações que envolvem muitos dados entre duas partes. Ela usa a mesma chave para criptografar e descriptografar – essa chave é análoga ao seu conceito de senha muito longa. Problema: como você compartilha sua chave / senha em primeiro lugar? Acontece que você não pode usar um canal seguro que é construído exclusivamente em um algoritmo de criptografia simétrica sem descobrir uma maneira de primeiro compartilhar sua chave / senha.

É aqui que entram os algoritmos assimétricos, mas são consideravelmente mais lentos do que algoritmos simétricos. Impraticável para transmitir grandes quantidades de dados, mas bom se você transmitir ou trocar algo pequeno como uma chave / senha de criptografia simétrica. Depois de fazer isso, você pode usar a criptografia simétrica para comunicações.

Uma das duas chaves para criptografia assimétrica é designada como chave pública e a outra como chave privada. A chave pública pode ser distribuída a todos, mas a chave privada deve ser mantida em segredo.

You (has pub) Server (has prv + pub) asym-encrypt(pub, sym-key/pwd) ----> asym-decrypt(prv, encrypted-data) => sym-key/pwd 

pub = chave pública, prv = chave privada

Em qualquer caso, esta explicação é uma simplificação do que o SSH realmente faz. Duas outras coisas que vale a pena destacar:

• Diffie Hellman é o algoritmo assimétrico de troca de chave típico. Com Diffie Hellman, você não precisa realmente criar uma chave simétrica . Ambas as partes criam a chave simétrica juntas durante a troca de chaves, o que é um bom recurso de segurança. Consulte " Diffie-Hellman Key Exchange " em inglês simples .

• Em minha explicação, presumi que você encontrou a chave pública do servidor e que confia que ela é a correta. Mas você realmente deve ter cuidado com as chaves públicas confiável. Para confiar em uma chave pública, ela deve ser assinada digitalmente. Uma chave pública assinada também é conhecida como um certificado.

Esperamos que isso esclareça as questões sobre senhas longas e chaves públicas e tem informações suficientes para você se aprofundar de uma forma mais significativa.