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. »
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.
|