--Apple-Mail-98BBA372-7181-443F-8914-16EC10B44A55
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
COMPLÉMENT
J’ai approfondi ma vérification.
J’étais parti sur le seul schéma habituel : chiffrer avec la clef publique et déchiffrer avec la clef privée.
Je crois que tu voulais parler de signature numérique, où Alice (ici le client ssh) chiffre avec sa clef privée probablement un message fourni par Bob (ici le serveur ssh). Bob « déchiffre le message d’Alice » avec la clef publique. Il est alors
certain que ça vient d’Alice et lui ouvre la porte.
C’est ça ?
Il m’échappe encore un truc que je vais explorer : je ne comprends pas comment Bob peut déchiffrer avec la clef publique d’Alice un message d’Alice.
J’imagine qu’il s’agit en fait seulement de « vérifier que la signature provient d’Alice ».
Je fouille dans ce sens.
Peux-tu expliquer le procédé ?
Source :
« If Alice encrypts a message using her private key and sends the encrypted message to Bob, then Bob can be sure that the data he receives comes from Alice; if Bob can decrypt the data with Alice's public key, the message must have been encrypted by
Alice with her private key, and only Alice has Alice's private key. The problem is that anybody else can read the message as well because Alice's public key is public. Although this scenario does not allow for secure data communication, it does provide
the basis for digital signatures. »
https://www.ibm.com/docs/en/sdk-java-technology/8?topic=processes-public-key-cryptography
Début du message transféré :
De: RogerT <roger.tarani@free.fr>
Date: 19 juillet 2023 à 16:59:28 UTC+2
À: debian-user-french@lists.debian.org
Objet: Rép. : Authentification ssh et PAM
Le 19 juil. 2023 à 16:32, Michel Verdier <mv524@free.fr> a écrit :
Le 19 juillet 2023 RogerT a écrit :
Pour chiffrer une phrase il suffit de la clef publique.
Pour déchiffrer une phrase il faut la clef privée.
Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
diffuses la publique à tous ceux qui doivent déchiffrer
Après vérification, et sauf erreur ou omission de ma part, je regrette mais en cryptographie asymétrique, seule la clef privée permet de DÉchiffrer.
Tandis que la clef publique permet à tout le monde de chiffrer un message.
En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me tromperais alors que c’est le premier cas de figure ultra connu entre Alice et Bob pour échanger un secret (chiffré avec la clef publique et déchiffré avec la seule
clef privée).
Le serveur a seulement la clef publique.
Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
lesquels tu dois te connecter) ont la publique
Le serveur distant a la clef publique que j’y ai copié. Mais pas pour déchiffrer. Voir plus haut. Sauf erreur ou omission.
Le client a les deux clefs.
Seul le client peut déchiffrer une phrase chiffrée.
Non, seul le client peut chiffrer
Tous ceux qui ont la clef publique peuvent chiffrer.
Et aussi celui qui a seulement la clef privée car elle permet de générer une clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)
Comment fait le serveur ssh pour savoir que c’est bien le détenteur de >>> la clef privée qui frappe à la porte ?
Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
client avec sa clef privée
Toujours pas d’accord.
Peut-être as-tu un détail de la séquence entre client et serveur ?
L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
facteurs d'authentification.
Ça enlève l’intérêt d’une authentification rapide.
Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe… >>
Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles.
sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef >>>> pour qu'elle soit accessible par le client.
Entendu.
Modulo le nom du dev /dev/sdb …
Sauf à utiliser un UUID pour le device (ça se fait, je crois).
oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
l'option user, et le client fait un mount du nom du répertoire que tu
précise. Par exemple chez moi :
#/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f42f95e2-01"
LABEL="CLEF" /media/usb vfat user,noexec,noauto,noatime,lazytime 0 2
PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat user,noexec,noauto,noatime,lazytime 0 0
/dev/mmcblk0p1 /media/sd xfs user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime 0 0
Ok. Merci.
Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et
aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute
utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
LDAP).
A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les >> PAM pour établir la session. Là ce que tu travailles c'est la
sécurisation d'une connexion ssh sur le client, donc à priori aucun
rapport avec les PAM.
Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
que tu insères une clef USB ?
Je ne sais pas trop.
PAM offre aux applications une interface standard pour l’authentification qui permet de s’affranchir du mécanisme sous-jacent. Je suis en train d’étudier PAM.
--Apple-Mail-98BBA372-7181-443F-8914-16EC10B44A55
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">COMPLÉMENT</div><div dir="ltr"><br></div><div dir="ltr">J’ai approfondi ma vérification. </div><div dir="
ltr"><br></div><div dir="ltr">J’étais parti sur le seul schéma habituel : chiffrer avec la clef publique et déchiffrer avec la clef privée. </div><div dir="ltr"><br></div><div dir="ltr">Je crois que tu voulais parler de <u>signature numérique<
, où Alice (ici le client ssh) chiffre avec sa clef privée probablement un message fourni par Bob (ici le serveur ssh). Bob « déchiffre le message d’Alice » avec la clef publique. Il est alors certain que ça vient d’Alice et lui ouvre la
porte.</div><div dir="ltr">C’est ça ?</div><div dir="ltr"><br></div><div dir="ltr">Il m’échappe encore un truc que je vais explorer : je ne comprends pas comment Bob peut déchiffrer avec la clef publique d’Alice un message d’Alice.</div><div
dir="ltr">J’imagine qu’il s’agit en fait seulement de « vérifier que la signature provient d’Alice ». </div><div dir="ltr">Je fouille dans ce sens. </div><div dir="ltr">Peux-tu expliquer le procédé ?</div><div dir="ltr"><br></div><
div dir="ltr">Source :</div><div dir="ltr"><span style="font-size: 16px; -webkit-text-size-adjust: auto; caret-color: rgb(22, 22, 22); color: rgb(22, 22, 22); font-family: "IBM Plex Sans", "Helvetica Neue", Arial, sans-serif;
background-color: rgb(255, 255, 255);">« If Alice encrypts a message using her private key and sends the encrypted message to Bob, then Bob can be sure that the data he receives comes from Alice; if Bob can decrypt the data with Alice's public key, the
message must have been encrypted by Alice with her private key, and only Alice has Alice's private key. The problem is that anybody else can read the message as well because Alice's public key is public. <u>Although this scenario does not allow for
secure data communication, it does provide the basis for digital signatures</u>. »</span></div><div dir="ltr"><br></div><div dir="ltr"><a href="
https://www.ibm.com/docs/en/sdk-java-technology/8?topic=processes-public-key-cryptography">https://www.ibm.
com/docs/en/sdk-java-technology/8?topic=processes-public-key-cryptography</a><br><br><br>Début du message transféré :<br><br></div><blockquote type="cite"><div dir="ltr"><b>De:</b> RogerT <
roger.tarani@free.fr><br><b>Date:</b> 19 juillet
2023 à 16:59:28 UTC+2<br><b>À:</b>
debian-user-french@lists.debian.org<br><b>Objet:</b> <b>Rép. : Authentification ssh et PAM</b><br><br></div></blockquote><blockquote type="cite"><div dir="ltr"><span></span><br><span></span><br><blockquote
type="cite"><span>Le 19 juil. 2023 à 16:32, Michel Verdier <
mv524@free.fr> a écrit :</span><br></blockquote><blockquote type="cite"><span>Le 19 juillet 2023 RogerT a écrit :</span><br></blockquote><blockquote type="cite"><span></span><br></
blockquote><blockquote type="cite"><blockquote type="cite"><span>Pour chiffrer une phrase il suffit de la clef publique. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Pour déchiffrer une phrase il faut la
clef privée.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu</span><br></blockquote><blockquote type="cite"><
span>diffuses la publique à tous ceux qui doivent déchiffrer</span><br></blockquote><span></span><br><span>Après vérification, et sauf erreur ou omission de ma part, je regrette mais en cryptographie asymétrique, seule la clef privée permet de DÉ
chiffrer. </span><br><span>Tandis que la clef publique permet à tout le monde de chiffrer un message. </span><br><span></span><br><span>En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me tromperais alors que c’est le
premier cas de figure ultra connu entre Alice et Bob pour échanger un secret (chiffré avec la clef publique et déchiffré avec la seule clef privée). </span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="
cite"><blockquote type="cite"><span>Le serveur a seulement la clef publique. </span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Oui, tous les serveurs qui doivent te déchiffrer (
= tous ceux sur</span><br></blockquote><blockquote type="cite"><span>lesquels tu dois te connecter) ont la publique</span><br></blockquote><span>Le serveur distant a la clef publique que j’y ai copié. Mais pas pour déchiffrer. Voir plus haut. Sauf
erreur ou omission. </span><br><span></span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>Le client a les deux clefs. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Seul le client
peut déchiffrer une phrase chiffrée.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Non, seul le client peut chiffrer</span><br></blockquote><span></span><br><span>Tous ceux qui
ont la clef publique peuvent chiffrer. </span><br><span>Et aussi celui qui a seulement la clef privée car elle permet de générer une clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)</span><br><span></span><br><blockquote
type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Comment fait le serveur ssh pour savoir que c’est bien le détenteur de</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><
span>la clef privée qui frappe à la porte ?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Parce qu'il décode, avec la clef publique, une phrase chiffrée par le</span><br></
blockquote><blockquote type="cite"><span>client avec sa clef privée</span><br></blockquote><span>Toujours pas d’accord. </span><br><span>Peut-être as-tu un détail de la séquence entre client et serveur ?</span><br><span></span><br><span></span><br><
blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><
blockquote type="cite"><span>facteurs d'authentification.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Ça enlève l’intérêt d’une authentification rapide.</span><br></blockquote></
blockquote><blockquote type="cite"><blockquote type="cite"><span>Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><
span>Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc</span><br></blockquote><span>Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd qui ont tous déjà été attaqués. Y compris dashlane. Voir divers
articles. </span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc</span><
</blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef</span><br></blockquote></blockquote></blockquote><blockquote
type="cite"><blockquote type="cite"><blockquote type="cite"><span>pour qu'elle soit accessible par le client.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Entendu.</span><br></blockquote></
blockquote><blockquote type="cite"><blockquote type="cite"><span>Modulo le nom du dev /dev/sdb …</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Sauf à utiliser un UUID pour le device (ça se fait, je crois).</
span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec</span><br></blockquote><blockquote type="cite"><span>l'
option user, et le client fait un mount du nom du répertoire que tu</span><br></blockquote><blockquote type="cite"><span>précise. Par exemple chez moi :</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"
<span>#/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f42f95e2-01"</span><br></blockquote><blockquote type="cite"><span>LABEL="CLEF" /media/usb
vfat user,noexec,noauto,noatime,lazytime 0 2</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>PARTUUID="42711922-2694-43bd-bf1f-
9d6a7fccebec" /media/backup exfat user,noexec,noauto,noatime,lazytime 0 0</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>/dev/
mmcblk0p1 /media/sd xfs user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime 0 0</span><br></blockquote><span>Ok. Merci. </span><br><span></span><br><span></span><br><blockquote type="cite"><
blockquote type="cite"><span>Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>aller au-delà d’indiquer le chemin de la clef (avec
ssh -i) il faut sans doute</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification</span><br></blockquote></blockquote><blockquote type="cite">
<blockquote type="cite"><span>LDAP).</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les</span><br></blockquote>
<blockquote type="cite"><span>PAM pour établir la session. Là ce que tu travailles c'est la</span><br></blockquote><blockquote type="cite"><span>sécurisation d'une connexion ssh sur le client, donc à priori aucun</span><br></blockquote><blockquote
type="cite"><span>rapport avec les PAM.</span><br></blockquote><blockquote type="cite"><span>Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès</span><br></blockquote><blockquote type="cite"><span>que tu insères une clef USB ?</
span><br></blockquote><span></span><br><span>Je ne sais pas trop. </span><br><span>PAM offre aux applications une interface standard pour l’authentification qui permet de s’affranchir du mécanisme sous-jacent. Je suis en train d’étudier PAM. </
span><br><span></span><br></div></blockquote></body></html> --Apple-Mail-98BBA372-7181-443F-8914-16EC10B44A55--
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)