Un utilisateur dispose d'une clef ssh privée et d'une clef publique
rangés dans ~/.ssh/ , avec des droits 600.
S'il a copié la clef publique sur un serveur distant, l'agent local
saura "lier la clef publique et la privée" pour lui donner accès à l'hôte distant sans besoin de saisir id et pwd.
Classique.
Quel est le mécanisme détaillé conduisant à l'authentification de l'utilisateur par l'hôte distant ?
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
Stocker la clef privée localement avec pour seule protection des droits 600 me semble léger même si c'est habituel.
Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
par le système ?
En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué.
https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte local et le HSM afin de réaliser une authentification ssh ?
Comment faut-il faire ?
Le 19 juil. 2023 à 00:00, ajh-valmer <ajh.valmer@free.fr> a écrit :
Il suffit de taper 3 mots dans un moteur de recherche : www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
:-)
On Tuesday 18 July 2023 18:16:21 roger.tarani@free.fr wrote:
Un utilisateur dispose d'une clef ssh privée et d'une clef publique
rangés dans ~/.ssh/ , avec des droits 600.
S'il a copié la clef publique sur un serveur distant, l'agent local
saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
distant sans besoin de saisir id et pwd.
Classique.
Quel est le mécanisme détaillé conduisant à l'authentification de
l'utilisateur par l'hôte distant ?
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef
privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
Stocker la clef privée localement avec pour seule protection des droits 600 >> me semble léger même si c'est habituel.
Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée >> par le système ?
En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué.
https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte >> local et le HSM afin de réaliser une authentification ssh ?
Comment faut-il faire ?
Quel est le mécanisme détaillé conduisant à l'authentification de l'utilisateur par l'hôte distant ?
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
Stocker la clef privée localement avec pour seule protection des droits 600 me semble léger même si c'est habituel.
Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une
clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système
En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte local et le HSM afin de réaliser une authentification ssh ?
Comment faut-il faire ?
Le 19 juil. 2023 à 10:08, didier gaumet <didier.gaumet@gmail.com> a écrit :
je n'y connais rien mais tu peux éventuellement consulter ce qui suit:
- sur le fonctionnement général de PAM: la vieille doc de kernel.org (The Linux-PAM System Administrators' Guide) n'est plus semble-t-il disponible sur le site d'origine mais on la dtouve encore ailleurs:
https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
la mage man de PAM(8) peut aussi être consultée
- sur le principe général (avec diagrammes, plus visuels) de l'emploi des smartcards (sous-type de HSM); RedHat propose cette doc:
https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8
- sur la configuration particulière nécessaire à cet usage en liaison avec des applis/serveurs, Red Hat propose cette doc:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening
Le 19 juil. 2023 à 09:05, Michel Verdier <mv524@free.fr> a écrit :
Le 18 juillet 2023 roger tarani a écrit :
Quel est le mécanisme détaillé conduisant à l'authentification de l'utilisateur par l'hôte distant ?
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
La clef publique est indiquée au serveur lors de la demande de connexion.
Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le client avec sa clef privée.
Ça enlève l’intérêt d’une authentification rapide.Stocker la clef privée localement avec pour seule protection des droits 600 me semble léger même si c'est habituel.
L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2 facteurs d'authentification.
Entendu.Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une
clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système
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.
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).En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué.
https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte local et le HSM afin de réaliser une authentification ssh ?
Comment faut-il faire ?
Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une authentification PAM passe par ssh et pas par le login habituel ?
Merci beaucoup pour tes pointeurs. Je vais étudier ça.
Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection beaucoup plus courte que la clef elle-même 2048 bits.
En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le système via PAM ? (Je me dis que oui, car je crois savoir que l’authentification par LDAP passe par PAM).
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci.
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
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 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 client a les deux clefs.
Seul le client peut déchiffrer une phrase chiffrée.
Non, seul le client peut chiffrer
Toujours pas d’accord.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
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.L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2Ça enlève l’intérêt d’une authentification rapide.
facteurs d'authentification.
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
Ok. Merci.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 clefEntendu.
pour qu'elle soit accessible par le client.
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
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 ?
Pour chiffrer une phrase il suffit de la clef publique.
Pour déchiffrer une phrase il faut la clef privée.
Le serveur a seulement la clef publique.
Le client a les deux clefs.
Seul le client peut déchiffrer une phrase chiffrée.
Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
la clef privée qui frappe à la porte ?
L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2Ça enlève l’intérêt d’une authentification rapide.
facteurs d'authentification.
Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
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 clefEntendu.
pour qu'elle soit accessible par le client.
Modulo le nom du dev /dev/sdb …
Sauf à utiliser un UUID pour le device (ça se fait, je crois).
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).
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.
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.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
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.
Le 19 juil. 2023 à 17:58, Michel Verdier <mv524@free.fr> a écrit :
Le 19 juillet 2023 RogerT a écrit :
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.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 est validé par le gouvernement https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) avaient du
stockage en ligne, ce n'est pas le cas de keepass. As-tu les références d'articles ?
<div dir="ltr">L’éditeur n’a pas craint d’affirmer :</div><div dir="ltr">« <span style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: "PT Sans"; font-size: 16px; text-align: justify; -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">l'éditeur de KeePass estime que la base de données de mots de passe n'est pas censée être protégée contre un attaquant disposant déjà d'un accès local sur un PC.</span> »</div><div dir="
pour moi crypter et décrypter ne sont que des mots
Le 20 juil. 2023 à 10:16, didier gaumet <didier.gaumet@gmail.com> a écrit :pas un double chiffrement par les deux clés publiques, c'est un double chiffrement par la clé privée de l'émetteur puis la clé publique du destinataire ;-)
Le 20/07/2023 à 09:25, Michel Verdier a écrit :
Le 19 juillet 2023 didier gaumet a écrit :
Pour autant que ça s'applique ici, Wikipedia a une explication d'un mécanismeEn français c'est mieux :)
d'autentification à clés asymétriques par l'utilisation d'un double
chiffrement avec les deux clés publiques (celles de chaque partie):
https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.
Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on se le dise ;-)
D'ailleurs c'est à se demander quel phénomène occulte et maléfique est intervenu pour corrompre et distordre mon message précédent, puisque à le lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je me suis encore planté (c'est
Encore une preuve qu'il ne faut pas faire aveuglément confiance à un contributeur mais valider l'exactitude et la pertinence de ses propos :-)
En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de configurer account, auth, password, session) ou faut-il trouver/développer un composantlogiciel pour interagir avec chaque type ou modèle de HSM ?
De: "elguero eric" <elgueroeric@yahoo.fr>
À: debian-user-french@lists.debian.org
Envoyé: Mercredi 19 Juillet 2023 18:28:24
Objet: Re: Authentification ssh et PAM
pour moi crypter et décrypter ne sont que des mots
et en réalité il s'agit de deux bijections inverses
l'une de l'autre. donc on peut aussi bien dire qu'on commence
par décrypter un message avant de l'envoyer et
que le récipiendaire devra alors le crypter pour retrouver
le message original. Ou l'inverse.
e.e.
Le mercredi 19 juillet 2023 Ã 18:08:00 UTC+2, Michel Verdier
<mv524@free.fr> a écrit :
Le 19 juillet 2023 RogerT a écrit :
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.
Oui tu as raison, autant pour moi, ça fait du bien de relire les
bases de
temps en temps. Voilà une description assez claire : https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process
Le 18 juillet 2023 roger tarani a écrit :
Quel est le mécanisme détaillé conduisant à l'authentification de l'utilisateur par l'hôte distant ?
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
La clef publique est indiquée au serveur lors de la demande de connexion.
Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
client avec sa clef privée.
La validation par le gouvernement n’est en rien une garantie (sgdg…).
Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité d’exporter en clair les pwds :
https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/
Encore une nouvelle faille en 2023 : CVE-2023-35866
19/07/2023 https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
Le 21 juil. 2023 à 10:26, Michel Verdier <mv524@free.fr> a écrit :
Le 19 juillet 2023 RogerT a écrit :
La validation par le gouvernement n’est en rien une garantie (sgdg…).
Bien sûr, mais c'est quand même un plus par rapport à rien du tout.
Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité d’exporter en clair les pwds :
https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne sont pas touchés. Et ça concerne le paramétrage du client pas la
base elle-même.
Encore une nouvelle faille en 2023 : CVE-2023-35866
19/07/2023
https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
d'accès. A partir de là forcément n'importe quoi peut être fait sur la base et sans doute aussi sur le poste. Ce CVE est disputé.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 168:47:39 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,551 |