Comment fonctionnent les clés SSH? [dupliquer]

En gros, quest-ce qui le rend meilleur quun mot de passe vraiment long?

Ils ne sont pas transférés vers le serveur (car même le très long mot de passe doit être transféré). Il n’est pas non plus sûr dans le cas ssh (le canal est chiffré sauf si vous utilisez des chiffrements cassés), mais en théorie, il peut être intercepté par Man In the middle ou (super) utilisateur malveillant sur le serveur distant.

Et comment la clé publique joue-t-elle un rôle?

Cest le point de la cryptographie asymétrique. La clé privée crée la signature et le public peut vérifier que la signature a été faite par la clé publique respective. Vous envoyez la clé publique et la signature des données proposées par le serveur et cela suffit pour que le serveur vous autorise laccès (si la clé publique correspond à celle de authorized_keys).

Commentaires

• Donc, il envoie la clé publique, si elle correspond alors les données qui reviennent sont chiffrées avec cette clé publique, que la clé privée peut ensuite déchiffrer ? Et vice versa avec le chiffrement privé et le déchiffrement public?
• chiffré avec cette clé publique, que la clé privée peut ensuite déchiffrer – signé avec une clé privée, quelle clé publique peut vérifier.
• Que signifie " signé "? Quest-ce qui empêche quelque chose de déchiffrer quelque chose même si la signature nest pas extraite?
• @amflare: en.wikipedia.org/wiki/Digital_signature Si quelque chose, alors le code du déchiffreur potentiel '.
• Daccord, je comprends cela. Doù mon hypothèse (apparemment erronée) que les clés ont permis le cryptage et le décryptage. Mais il semble que si jétais une partie malveillante, je pourrais intercepter les données, ignorer lauthenticité de la signature et essayer de la déchiffrer quand même. Javais limpression que les clés servaient également à empêcher des tiers de le faire.

Je ne suis pas sûr de ce que vous comparez SSH avec le « mot de passe très long ». SSH fournit un moyen sécurisé denvoyer votre nom dutilisateur et votre mot de passe à un serveur distant. Ou vous pouvez utiliser la clé publique dun client. Les clés asymétriques sont généralement plus difficiles à briser car elles ne sont pas soumises à la création de mauvais mots de passe par les utilisateurs. Lauthentification par clé publique est préférée pour cette raison. Vous pouvez mettre en liste blanche des clés publiques spécifiques pour votre utilisateur (et votre adresse IP) afin que tout le monde ne puisse pas se connecter avec votre nom dutilisateur et depuis nimporte quel ordinateur. Cette liste blanche est contenue dans /home/<user>/.ssh/authorized_keys.

Bases de SSH:

1. Le serveur présente sa clé publique RSA à le client. Le client vérifie manuellement quil fait confiance à cette clé avant de continuer.

2. SSH utilise Diffie Hellman pour établir une valeur secrète partagée.

3. Le secret partagé ainsi que de nombreuses données déchange de clés sont hachés ensemble et signés à laide de la clé privée du serveur.

4. Le client peut vérifier cette signature en utilisant les anciens serveurs clé publique de confiance.

5. Les deux parties disposent désormais de toutes les informations nécessaires pour générer des clés de session.

De la section 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. 

Une fois le canal chiffré établi, le protocole SSH commence lauthentification client basée sur les paramètres que vous lui avez donnés. Tout cela est effectué en toute sécurité via le canal crypté.

Permettez-moi de vous donner une image de haut niveau. De toute évidence, vous comprenez le besoin de communications sécurisées, que ce soit SSH ou HTTPS. Les communications sécurisées signifient que le canal est crypté.

De manière générale, tous les algorithmes de cryptage appartiennent à lune des deux catégories suivantes:

• Cryptage symétrique. Une clé. La même clé est utilisée pour crypter et décrypter. Vite. Par exemple. AES.
• Cryptage asymétrique. Deux clés. Lun ou lautre peut être utilisé pour chiffrer, mais seul lautre peut déchiffrer. Beaucoup plus lent que les algorithmes symétriques. Par exemple. RSA.

Le cryptage symétrique est rapide et donc adapté aux communications impliquant beaucoup de données entre deux parties. Il utilise la même clé pour le cryptage et le décryptage – cette clé est analogue à votre concept de mot de passe très long. Problème: comment partagez-vous votre clé / mot de passe en premier lieu? Il savère que vous ne pouvez pas utiliser un canal sécurisé basé uniquement sur un algorithme de cryptage symétrique sans trouver un moyen de partager dabord votre clé / mot de passe.

Cest là que les algorithmes asymétriques entrent en jeu, mais sont considérablement plus lents que algorithmes symétriques. Pas pratique pour transmettre de grandes quantités de données, mais très bien si vous transmettez ou échangez quelque chose de petit comme une clé / mot de passe de cryptage symétrique. Une fois que cela est fait, vous pouvez maintenant utiliser le cryptage symétrique pour les communications.

Lune des deux clés pour le cryptage asymétrique est désignée comme la clé publique et lautre la clé privée. La clé publique peut être distribuée à tout le monde, mais la clé privée doit être gardée secrète.

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

pub = clé publique, prv = clé privée

Dans tous les cas, cette explication est une simplification de ce que fait réellement SSH. Deux autres choses méritent dêtre soulignées:

• Diffie Hellman est lalgorithme asymétrique déchange de clés typique. Avec Diffie Hellman, vous navez pas réellement besoin de créer une clé symétrique . Les deux parties créent la clé symétrique ensemble pendant léchange de clé, ce qui est une fonctionnalité de sécurité intéressante. Voir " Échange de clés Diffie-Hellman " en anglais clair .

• Dans mon explication, jai supposé que vous aviez trouvé la clé publique du serveur et que vous croyiez que cétait la bonne. Mais vous devriez vraiment faire attention aux clés publiques que vous trust. Pour faire confiance à une clé publique, elle doit être signée numériquement. Une clé publique signée est également connue sous le nom de certificat.

Jespère que cela clarifie les questions relatives aux mots de passe longs et clés publiques, et dispose de suffisamment dinformations pour que vous puissiez approfondir de manière plus significative.