Connection SSH par clé privée : CCM ?
Résolu/Fermé
DoctorAngry
Messages postés
158
Date d'inscription
samedi 16 mars 2019
Statut
Membre
Dernière intervention
9 mars 2022
-
11 sept. 2021 à 22:40
mamiemando Messages postés 33432 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 16 décembre 2024 - 23 sept. 2021 à 11:56
mamiemando Messages postés 33432 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 16 décembre 2024 - 23 sept. 2021 à 11:56
A voir également:
- Connection SSH par clé privée : CCM ?
- Clé windows 10 gratuit - Guide
- Clé usb non détectée - Guide
- Navigation privée - Guide
- Gmail connection - Guide
- Clé bootable windows 10 - Guide
3 réponses
barnabe0057
Messages postés
14454
Date d'inscription
lundi 2 mars 2009
Statut
Contributeur
Dernière intervention
30 novembre 2024
4 918
Modifié le 11 sept. 2021 à 23:31
Modifié le 11 sept. 2021 à 23:31
Bonjour,
L'homme du milieu ne possède pas la clé privée, par conséquent il ne sera pas en mesure de chiffrer le message aléatoire envoyé par le serveur.
L'homme du milieu ne possède pas la clé privée, par conséquent il ne sera pas en mesure de chiffrer le message aléatoire envoyé par le serveur.
DoctorAngry
Messages postés
158
Date d'inscription
samedi 16 mars 2019
Statut
Membre
Dernière intervention
9 mars 2022
128
13 sept. 2021 à 10:44
13 sept. 2021 à 10:44
Personne d'autre n'a d'idée ?
mamiemando
Messages postés
33432
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
16 décembre 2024
7 809
13 sept. 2021 à 12:23
13 sept. 2021 à 12:23
Bonjour,
En chiffrement asymétrique, la clé publique sert à chiffrer, et la clé privée sert à déchiffrer. (affirmation vraie ?)
Vrai.
Comment expliquer qu'ici, la clé publique sert à déchiffrer ?
Tu peux voir une clé publique comme un cadenas et la clé privée correspondante comme la clé pour ouvrir ce cadenas. En soit pas de problème pour mettre des cadenas sur des serveurs, tant que tu es le seul en détenir la clé. En ce sens, la clé privée atteste de ton identité, puisque tu es le.la seul.e à pouvoir ouvrir ledit cadenas. C'est ce qui est expliqué de manière plus technique dans l'introduction de cet article wikipedia. Une autre manière de dire les choses est qu'une clé privée est installée côté client (et pas ailleurs) et la clé publique est installée côté serveur.
Comme le dit ce lien, c'est pour ça qu'il n'y a pas de problème à copier sa clé publique sur des machines tierces, et qu'il ne faut bien entendu jamais disséminer sa clé privée. Rappelons au passage que copier sa clé privée sur une machine qui n'est pas de confiance (donc, non personnelle, e.g. un serveur en entreprise) est toujours une mauvaise idée. On utiliserait plutôt ssh-agent pour transporter son identité de manière transparente.
Au moment de s'authentifier, un challenge est envoyé par le serveur au client. Cela permet de vérifier qu'il possède bien la clé privée correspondant à l'une des clés publiques installées au compte auquel le client tente de se connecter. Pour rappel, les clés publiques autorisées (donc les cadenas) sont listées dans
Ce challenge est réalisé en se basant sur le fait que, étant donnée une clé publique, seul le détenteur de la clé privée peut répondre au challenge correspondant. Si un message a été chiffré avec une clé publique, seul un détenteur de la clé privée correspondante peut le déchiffrer. Le challenge est donc chiffré avec la clé publique (c'est la seule que le serveur détient en général) et le client, disposant de la clé privée correspondante peut alors se connecter. Et sinon, la connexion est refusée par le serveur.
Pour plus de détails sur cette étape, tu peux aussi lire cette discussion et cette discussion).
En pratique, si le client s'est connecté à
Une fois la connexion établie, le client et le serveur se sont mis d'accord sur la paire de clé à utiliser pour communiquer. Le client utilise la clé privée pour chiffrer les messages envoyés au serveur (voir cette discussion) que le serveur déchiffre avec la clé publique. Le serveur chiffre ses messages avec la clé publique qui sont déchiffrés côté client avec la clé privée.
Le man in the middle (MITM pour les intimes)
Un man in the middle est une attaque qui consiste à intercepter le trafic entre deux parties et à se faire passer pour l'une d'elle. Ces deux machines peuvent typiquement être un client et un serveur ssh, mais ce type d'attaque n'est pas spécifique à une architecture client / serveur ou à un protocole donné.
Si tu veux en savoir plus sur les MITM avec ssh, tu peux regarder ce lien. Il montre en quoi un MITM avec ssh est possible, mais difficile à mettre en œuvre.
Bonne chance
En chiffrement asymétrique, la clé publique sert à chiffrer, et la clé privée sert à déchiffrer. (affirmation vraie ?)
Vrai.
Comment expliquer qu'ici, la clé publique sert à déchiffrer ?
sshcomment ça marche
Tu peux voir une clé publique comme un cadenas et la clé privée correspondante comme la clé pour ouvrir ce cadenas. En soit pas de problème pour mettre des cadenas sur des serveurs, tant que tu es le seul en détenir la clé. En ce sens, la clé privée atteste de ton identité, puisque tu es le.la seul.e à pouvoir ouvrir ledit cadenas. C'est ce qui est expliqué de manière plus technique dans l'introduction de cet article wikipedia. Une autre manière de dire les choses est qu'une clé privée est installée côté client (et pas ailleurs) et la clé publique est installée côté serveur.
Comme le dit ce lien, c'est pour ça qu'il n'y a pas de problème à copier sa clé publique sur des machines tierces, et qu'il ne faut bien entendu jamais disséminer sa clé privée. Rappelons au passage que copier sa clé privée sur une machine qui n'est pas de confiance (donc, non personnelle, e.g. un serveur en entreprise) est toujours une mauvaise idée. On utiliserait plutôt ssh-agent pour transporter son identité de manière transparente.
Au moment de s'authentifier, un challenge est envoyé par le serveur au client. Cela permet de vérifier qu'il possède bien la clé privée correspondant à l'une des clés publiques installées au compte auquel le client tente de se connecter. Pour rappel, les clés publiques autorisées (donc les cadenas) sont listées dans
~/.ssh/authorized_keys, où
~désigne le dossier personnel associé au compte ssh.
Ce challenge est réalisé en se basant sur le fait que, étant donnée une clé publique, seul le détenteur de la clé privée peut répondre au challenge correspondant. Si un message a été chiffré avec une clé publique, seul un détenteur de la clé privée correspondante peut le déchiffrer. Le challenge est donc chiffré avec la clé publique (c'est la seule que le serveur détient en général) et le client, disposant de la clé privée correspondante peut alors se connecter. Et sinon, la connexion est refusée par le serveur.
Pour plus de détails sur cette étape, tu peux aussi lire cette discussion et cette discussion).
En pratique, si le client s'est connecté à
toto@serverle serveur challenge le client avec chaque clé publique référencée dans
~toto/.ssh/authorized_keys. De son côté, le client tente à l'aide de sa (ou ses) clé(s) privée(s) (e.g.
~/.ssh/id_rsa) de répondre au challenge.
Une fois la connexion établie, le client et le serveur se sont mis d'accord sur la paire de clé à utiliser pour communiquer. Le client utilise la clé privée pour chiffrer les messages envoyés au serveur (voir cette discussion) que le serveur déchiffre avec la clé publique. Le serveur chiffre ses messages avec la clé publique qui sont déchiffrés côté client avec la clé privée.
Le man in the middle (MITM pour les intimes)
Un man in the middle est une attaque qui consiste à intercepter le trafic entre deux parties et à se faire passer pour l'une d'elle. Ces deux machines peuvent typiquement être un client et un serveur ssh, mais ce type d'attaque n'est pas spécifique à une architecture client / serveur ou à un protocole donné.
Si tu veux en savoir plus sur les MITM avec ssh, tu peux regarder ce lien. Il montre en quoi un MITM avec ssh est possible, mais difficile à mettre en œuvre.
Bonne chance
DoctorAngry
Messages postés
158
Date d'inscription
samedi 16 mars 2019
Statut
Membre
Dernière intervention
9 mars 2022
128
21 sept. 2021 à 22:19
21 sept. 2021 à 22:19
Bonsoir,
Un immense merci pour cet éclairage digne d'un cours de fac.
Merci également pour les liens qui sont tout autant éclairant.
Cet échange aidera j'espère d'autres personnes comme moi qui avaient du mal à saisir la (les) chose(s).
Encore merci,
Cdt
DrA
Un immense merci pour cet éclairage digne d'un cours de fac.
Merci également pour les liens qui sont tout autant éclairant.
Cet échange aidera j'espère d'autres personnes comme moi qui avaient du mal à saisir la (les) chose(s).
Encore merci,
Cdt
DrA
mamiemando
Messages postés
33432
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
16 décembre 2024
7 809
>
DoctorAngry
Messages postés
158
Date d'inscription
samedi 16 mars 2019
Statut
Membre
Dernière intervention
9 mars 2022
23 sept. 2021 à 11:56
23 sept. 2021 à 11:56
Merci pour les compliments, et bonne continuation :-)
12 sept. 2021 à 01:33
Mais comment le serveur peut-il déchiffrer un message à l'aide d'une clé publique ?