Re: 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.
Reply to: