. <\/em>Ce qui rend cet algorithme particulièrement sécurisé, c’est le fait que la clé n’est jamais transmise entre le client et l’hôte. Au lieu de cela, les deux ordinateurs partagent des données publiques, puis les manipulent pour calculer de manière indépendante la clé secrète. Même si une autre machine capture les données publiquement partagées, il ne sera pas capable de calculer la clé car l’algorithme d’échange de clés n’est pas connu.<\/p>Il faut toutefois noter que la clé secrète est spécifique à chaque session SSH et est générée avant l’authentification du client. Une fois la clé générée, tous les paquets qui se déplacent entre les deux machines doivent être cryptés par la clé privée. Cela inclut le mot de passe tapé dans la console par l’utilisateur, de sorte que les informations d’identification sont toujours protégées des sniffers de paquets réseau.<\/p>
Il existe une variété de chiffrages symétriques, y compris, mais sans s’y limiter, AES (Advanced Encryption Standard), CAST128, Blowfish, etc. Avant d’établir une connexion sécurisée, le client et un hôte décident quel chiffrage utiliser, en publiant une liste des chiffrages compatibles, par ordre de préférence. Le chiffrage préféré des cybers clients pris en charge sur la liste de l’hôte est utilisé comme chiffrage bidirectionnel.<\/p>
Par exemple, si deux machines Ubuntu 14.04 LTS communiquent entre elles sur SSH, elles utiliseront aes128-ctr<\/strong> comme leur chiffrement par défaut.<\/p>Cryptage asymétrique<\/strong><\/h3>Contrairement au cryptage symétrique, le cryptage asymétrique utilise deux clés distinctes pour le cryptage et le décryptage. Ces deux clés sont appelées clé publique<\/strong> et clé privée<\/strong>. Ensemble, ces deux clés forment une paire de clés public-privé<\/strong>.<\/p>\n
\n\t\t\t\n\t\t\t\t<\/path>\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n<\/div>La clé publique, comme son nom l’indique, est distribuée et partagée ouvertement avec toutes les parties. Bien qu’elle soit étroitement liée à la clé privée en termes de fonctionnalité, la clé privée ne peut pas être calculée mathématiquement à partir de la clé publique. La relation entre les deux clés est très complexe : un message crypté par une clé publique d’une machine ne peut être déchiffré que par la clé privée d’une même machine. Cette relation à sens unique signifie que la clé publique ne peut pas décrypter ses propres messages, ni décrypter quelque chose de crypté par la clé privée.<\/p>
La clé privée doit rester privée, c’est-à-dire que la connexion doit être sécurisée, aucun tiers ne doit jamais la connaître. La force de l’ensemble de la connexion réside dans le fait que la clé privée n’est jamais révélée, car elle est le seul composant capable de décrypter des messages cryptés à l’aide de sa propre clé publique. Par conséquent, toute partie ayant la capacité de décrypter des messages signés publiquement doit posséder la clé privée correspondante.<\/p>
Contrairement à ce qu’on croit, le cryptage asymétrique n’est pas utilisé pour chiffrer toute la session SSH. Au lieu de cela, il n’est utilisé que pendant l’algorithme d’échange de clés de cryptage symétrique. Avant de lancer une connexion sécurisée, les deux parties génèrent des paires de clés public-privé temporaires et partagent leurs clés privées respectives pour produire la clé secrète partagée.<\/p>
Une fois qu’une communication symétrique sécurisée a été établie, le serveur utilise la clé publique des clients pour générer et contester et transmettre au client une authentification. Si le client peut décrypter avec succès le message, cela signifie qu’il dispose de la clé privée requise pour la connexion. La session SSH commence alors.<\/p>
Hashing (hachage)<\/strong><\/h3>Le hachage à sens unique est une autre forme de cryptographie utilisée dans les connexions Secure Shell. Les fonctions one-way-hash diffèrent des deux formes de cryptage ci-dessus en ce sens qu’elles ne sont jamais destinées à être déchiffrées. Elles génèrent une valeur unique d’une longueur fixe pour chaque entrée, dont aucune tendance claire ne peut être exploitée. Cela rend pratiquement impossible l’inversion.<\/p>
\n
\n\t\t\t\n\t\t\t\t<\/path>\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n<\/div>Il est facile de générer un hachage cryptographique à partir d’une entrée donnée, mais impossible de générer l’entrée du hash. Cela signifie que si un client détient l’entrée correcte, il peut générer le hachage cryptographique et comparer sa valeur pour vérifier s’il possède la bonne entrée.<\/p>
SSH utilise des hachages pour vérifier l’authenticité des messages. Ceci est fait en utilisant HMAC, ou Hash-based<\/strong> M<\/strong>essage A<\/strong>uthentication C<\/strong>odes. Cela garantit que la commande reçue n’est modifiée d’aucune manière que ce soit.<\/p>Même si l’algorithme de cryptage symétrique est sélectionné, un algorithme d’authentification de message approprié est également sélectionné. Cela fonctionne de manière similaire à la façon dont le chiffrage est sélectionné, comme expliqué dans la section sur le cryptage symétrique.<\/p>
Chaque message transmis doit contenir un MAC, qui est calculé en utilisant la clé symétrique, le numéro de séquence de paquets et le contenu du message. Il est envoyé en dehors des données cryptées symétriquement comme la partie finale du paquet de communication.<\/p>
![\"\"](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/46\/2022\/12\/Linux-cheat-sheet-FR-1024x283-1.png\/public\")
<\/a><\/figure>