Communication SSH à l'aide de clés publiques et privées

Question

J'essaie de comprendre comment fonctionne la méthode d'autorisation SSH car j'essaie de configurer un serveur git à l'aide de gitolite. Pour autant que je sache, gitolite utilisera le ssh pour autoriser les utilisateurs et leur donner accès à un référentiel spécifique avec des autorisations d'écriture et de lecture personnelles. Mais je suis confus au sujet de la façon dont l'autorisation fonctionnera.

J'ai regardé quelques vidéos sur YouTube et ils utilisent une analogie avec les couleurs pour expliquer. Si je comprends bien, pour deux personnes qui vont communiquer entre elles de manière secrète, elles ont besoin d'une clé secrète et publique. Les deux personnes se connaissent mutuellement et, pour communiquer entre elles, elles acceptent d'utiliser une clé publique. Pour établir une connexion, ils chiffrent la clé privée à l'aide de la même clé publique et transmettent le résultat à l'autre. Quand ils reçoivent le résultat, ils ajoutent la clé privée à ce message et, comme par magie, ils reçoivent le même message.

Mais je ne pense pas que je comprends bien parce que je ne peux pas voir comment le serveur va vérifier le client. Je sais que le serveur devait détenir les clés publiques des clients qui vont se connecter à lui, mais il a également obtenu une clé privée? Lorsque le client tente de se connecter à un serveur, il envoie sa clé privée chiffrée avec sa clé publique et le serveur crypte sa clé privée à l'aide de la clé publique du client et l'envoie au client.

Comment le serveur vérifie-t-il si l'utilisateur est vraiment lui? J'ai aussi lu que pour décrypter les informations cryptées avec une clé publique, seule la personne qui détient la clé privée peut déchiffrer le message. Alors, comment le serveur peut-il déchiffrer le message envoyé par le client s'il n'a pas la clé privée du client?

Si quelqu'un pouvait m'expliquer comment fonctionne l'authentification, l'autorisation et l'échange d'informations en utilisant ces clés publiques et privées, je serais très heureux.

Answer 1

de travaux SSH à peu près comme ce qui suit. Notez que ceci est simplement une explication de haut niveau:

Chaque partie a deux clés: une clé publique et une clé privée. Les clés publiques/privées sont mathématiquement liées, de sorte qu'elles sont fonctionnellement inverses. Ainsi, une opération effectuée par l'un ne peut être défaite que par l'autre. C'est complexe, mais penses-y comme si on calculait x^nnn par rapport à la nnnième racine de x. Le premier est facile mais le dernier est difficile, ce qui le rend impossible à deviner avec suffisamment de précision pour annuler l'opération. Cela nous donne quelques attributs souhaitables qui permettent à SSH de faire ce qui suit avec eux:

Le client se connecte au serveur. Le serveur prouve son identité en présentant un certificat signé avec sa clé privée. Le client utilise la clé publique du serveur pour décrypter le certificat et sait que seul le client aurait pu le chiffrer puisqu'il nécessite la clé privée. Le serveur fait ensuite la même chose avec un certificat présenté par le client. L'identification peut uniquement être effectuée avec une assurance de 100% en utilisant un tiers de confiance pour gérer les clés publiques. Sans le tiers, seuls les changements d'identité peuvent être détectés.Maintenant que les identités sont vérifiées, le serveur génère une clé secrète symétrique, la crypte avec la clé publique du client et l'envoie au client (qui est le seul à pouvoir déchiffrer le message puisqu'il requiert la clé privée). . À partir de ce moment, le client et le serveur ont la clé secrète symétrique et toute la communication est chiffrée avec cette clé. Ceci est fait pour des raisons de performances car les opérations de chiffrement symétrique sont environ 100 fois plus rapides que les opérations asymétriques.

Voici comment SSL vérifie les identités et crypte les informations. Notez que des contrôles d'accès plus granulaires sont fournis par des applications de niveau supérieur (telles que les autorisations de fichier * nix), et non SSL.

Answer 2

L'explication de ce sujet est un peu excessive pour le format Stackoverflow.

Il y a quelques jours Coursera a commencé un cours gratuit sur Cryptographie (partie I) qui explique exactement les questions qui vous intéressent.

Je vous souhaite la bienvenue à cryptography course pour trouver les réponses à vos questions