Re: Authentification ssh et PAM

[RogerT]

> Le 21 juil. 2023 à 10:26, Michel Verdier  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.

Ça ne vaut rien du tout. Rien.

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

C’est suffisamment grave et répété (pour d’autres gestionnaires de pwd) pour 
reconsidérer l’utilisation de ces passoires. 

« Disputed » : l’éditeur n’est pas d’accord. Ça ne veut rien dire d’autre 
(comme d’être partie à un procès dont on ignore l’issue). 
Avec des arguments pour keepass[xc] comme:
 « Oui, mais si un attaquant prend le contrôle de la machine alors il n’y a 
rien à faire » !!
 et « On ne peut pas faire de la sécurité en milieu non sûr » !!!
Ils sont fous ces gars !

Re: Authentification ssh et PAM

[Michel Verdier]

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

Re: Authentification ssh et PAM

[Vincent Lefevre]

On 2023-07-19 09:05:05 +0200, Michel Verdier wrote:
> 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.

Le chiffrage se fait avec la clé *publique* du destinataire. Mais
c'est HS ici, car il ne s'agit pas de chiffrer, mais d'authentifier,
qui est l'équivalent de vérifier une signature. Et la signature se
fait avec sa propre clé privée (et se vérifie avec la clé publique
associée).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Authentification ssh et PAM

[Jean Bernon]

Non je ne crois pas que ce soit des bijections inverses, sauf à s'entendre sur 
ce qu'on met derrière cette expression.

J'ai pioché la question du chiffrement il y a quelques années. Voici la petite 
synthèses que nous avions faite des principes de base. Elle ne répond pas à 
toutes questions de Roger. Mais elle peut aider à cadrer le débat.

Deux usages d'une paire de clés PGP dans l'échange de fichiers.

Premier usage : la paire de clés PGP permet de chiffrer / déchiffrer certains 
documents ou mails. Plus précisément, la clé publique sert au chiffrement et la 
clé privée au déchiffrement.

Deuxième usage : cette même paire de clés PGP peut aussi servir à signer 
électroniquement un mail (et à vérifier l’authenticité de la signature). Dans 
ce cas, la clé privée sert à signer et la clé publique à vérifier la signature.

Usages de GnuPG dans l'envoi d'un mail
Pourquoi ?  Qui ?   Comment ?
Chiffrement Expéditeur  Clé publique du destinataire
Déchiffrement   DestinataireClé privée du destinataire
Signature   Expéditeur  Clé privée de l'expéditeur
Vérification de la signatureDestinataireClé publique de l'expéditeur


- Mail original - 

> De: "elguero eric" 
> À: 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
>  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

Re: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 10:48, RogerT a écrit :
[...]

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 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

[...]

Rappel: je suis nul en sécurité donc je réponds sur ce point uniquement 
(à l'exclusion de tes autres interrogations) et ma réponse est à prendre 
avec des pincettes


- pour une clé USB (au sens large ça semble considéré comme un HSM 
aussi?) apparemment il y a le module PAM USB et la commande pamusb-conf, 
une page du wiki Debian évoque ça:

https://wiki.debian.org/pamusb

- pour les HSM plus évolués de type smartcard, de mémoire, un lien 
Redhat précédent semblait indiquer un standard PKCS#11 avec parfois des 
périphériques devant rajouter un pilote propriétaire. Le wiki Debian a 
une page sur les smartcards où il évoque deux standards, openPGP ou PKSC#11:

https://wiki.debian.org/fr/Smartcards?highlight=%28pkcs%2311%29

Re: Authentification ssh et PAM

[RogerT]

> Le 20 juil. 2023 à 10:16, didier gaumet  a écrit :
> 
> 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écanisme
>>> 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
>> En français c'est mieux :)
>> 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 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 ;-)
> 
> Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
> contributeur mais valider l'exactitude et la pertinence de ses propos :-)
> 
Bonjour,
Il faut toujours vérifier. 
Ça me semblait bizarre de chiffrer avec les deux clefs publiques. 

En vérifiant, j’ai redécouvert le mécanisme que je connaissais de chiffrement 
d’un fichier par l’expérience avec la clef publique du destinataire. 
C’est un mécanisme pour assurer la confidentialité. 

En revérifiant, j’ai découvert le mécanisme de chiffrement d’un (hash de) 
fichier avec la clef privée de l’expéditeur, qui permet au destinataire de 
vérifier que l’expéditeur est bien celui qui le revendique. 
C’est un mécanisme d’authentification (par signature). 

Et si on combine les deux (chiffrement par l’expéditeur avec sa clef privée 
d’un hash du fichier et avec la clef publique du fichier, alors on obtient une 
communication confidentielle et authentifiée. 

On peut donc supposer que le client ssh envoie simplement au serveur un message 
signé avec sa clef privée. Et le serveur ssh qui a une copie de la clef 
publique peut vérifier que celui qui demande la connexion est celui qu’il dit 
être (authentification). 

Échanger ici a permis de mettre les idées au clair. 
Merci. 

PS : une fois cette authentification configurée, il faut penser impérativement 
à désactiver l’authentification par pwd ou bien avoir un fail2ban installé pour 
éviter des intrusions qu’on croirait devenues impossibles sans avoir la clef 
privée si longue (RSA 2048 ou 4096).


J’ai commencé à étudier PAM et ses fichiers de configuration. 

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 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

Quelle est votre expérience pratique avec un HSM/une clef USB et PAM ?


PS : La question viendra ensuite de savoir quelle confiance on peut accorder à 
PAM en tant que « bus/slot/interface). Cad quelle garantie apporte-t-il de 
n’être pas un trou de sécurité ? 

Re: Authentification ssh et PAM

[Daniel Caillibaud]

Le 19/07/23 à 16:28, elguero eric  a écrit :
> pour moi crypter et décrypter ne sont que des mots

Mais les mots ont un sens ;-)

Et ici ce n'est pas le bon. En français, décrypter c'est déchiffrer un message 
dont on a pas la
clé de chiffrement (et crypter n'existe pas car ça n'a pas de sens, ça voudrait 
dire chiffrer
sans avoir la clé de chiffrement).

C'est pour ça qu'on parle de chiffrer / déchiffrer quand on code/décode un 
message en ayant la
clé.

En anglais, il n'y a pas de mot différent lorsqu'on a la clé ou pas, c'est 
toujours
encrypt/decrypt, d'où l'usage erroné très courant de crypter(sic)/décrypter en 
français.

-- 
Daniel

On tue un homme, on est un assassin.
On tue des millions d'hommes, on est un conquérant.
On les tue tous, on est un dieu.
Edmond Rostand

Re: Authentification ssh et PAM

[elguero eric]

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

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 17:58, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
 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. 
> 
> 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 ?


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/

L’éditeur n’a pas craint d’affirmer :
« 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. »

L’éditeur aurait aussi affirmé « on ne peut pas faire de la sécurité dans un 
environnement non sûr » !!! (j’ai lu ça ; je recherche la source). 

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/
L’éditeur écrit :
 "Pour l'instant, nous ne prévoyons pas de modifier radicalement le programme 
pour répondre à cette demande." - Et aussi : "La solution la plus simple pour 
contrer ce vecteur de menace est de verrouiller votre base de données avant de 
quitter votre poste de travail."


Rappel : ne quittez pas votre poste en laissant la BD déverrouillée :
https://security.stackexchange.com/questions/115086/is-it-safe-to-leave-keepass-always-opened-on-a-computer
 

On attend la révélation des autres failles ou faiblesses…

Re: Authentification ssh et PAM

[Michel Verdier]

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

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

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

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 ?

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 16:32, Michel Verdier  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. 

Re: Authentification ssh et PAM

[Michel Verdier]

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

> 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

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

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

> 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 ?

Re: Authentification ssh et PAM

[didier gaumet]

Le 19/07/2023 à 11:26, RogerT a écrit :

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.


rappel d'avertissement: je suis une tanche en réseau et sécurité, donc 
ne te fie surtout pas à mes suppositions sans te référer à des personnes 
dont tu estimes qu'elles ont une expertise valable et sans étudier avec 
esprit critique les solutions possibles.


J'ai l'*impression* (je suis une tanche) que les bonnes pratiques 
actuellement recommandent l'emploi de PAM au sein d'un groupe de 
solutions lorsqu'il s'agit d'un contexte réseau global (exemple: réseau 
d'une grosse entreprise, par opposition à un réseau d'un particulier 
offrant un unique service quelconque sans que les conséquences soient 
catastrophiques si il y a intrusion dans le réseau) ayant des impératifs 
de sécurité.


Mais j'ai l'*impression* qu'il est possible, même pour un administrateur 
réseau consciencieux et prudent, d'avoir laissé des trous dans sa config 
PAM qui permettent le contournement de PAM.


Donc j'ai l'*impression* aussi qu'il doit être possible de 
volontairement court-circuiter PAM pour employer un HSM, probablement 
dans un but de simplification


Mais j'ai aussi l'*impression* que ce serait potentiellement 
contre-productif puisque le but de PAM me semblant plus ou moins de 
border la sécurité d'accès en général et l'emploi d'un HSM représentant 
un cas d'emploi, ce serait alors potentiellement bizarre de vouloir 
contourner PAM par facilité.


Tu noteras que ça fait beaucoup d'impressions et qu'il ne serait pas 
sage de s'appuyer trop fort là-dessus ;-)


Si tu me permets une suggestion (amicale et d'un ignare du sujet), la 
réponse que t'a faite Michel Verdier par ailleurs pourrait laisser 
penser que comme moi, il s'interroge sur la clarté de tes objectifs 
(qu'est-ce que tu veux faire exactement?), et peut-être pourrais-tu 
essayer de débroussailler le but à atteindre sans dans un premier temps 
envisager les moyens à mettre en oeuvre (ici un HSM) car ça influe sur 
la réflexion


:-)

Re: Authentification ssh et PAM

[RogerT]

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 à 10:08, didier gaumet  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
> 

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 09:05, Michel Verdier  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.

Je ne comprends pas. 
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 ?
Je ne vois que ça : le serveur chiffre une phrase et l’envoie au client qui lui 
retourne déchiffrée. Il compare et constate si le client a su déchiffrer. C’est 
ça ?

>> 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.
Ç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…

> 
>> 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.
Entendu.
Modulo le nom du dev /dev/sdb …
Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

> 
>> 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 ?
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).

Re: Authentification ssh et PAM

[didier gaumet]

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

Re: Authentification ssh et PAM

[Michel Verdier]

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.

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

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

> 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 ?

Re: Authentification ssh et PAM

[RogerT]

Merci. 
Je connais l’usage.

Je voudrais savoir comment fonctionne le mécanisme d’authentification par clefs 
asymétriques permettant de donner l’accès à l’hôte distant. Qui fait quoi. 

Et surtout comment procéder pour utiliser un HSM ou une clef USB où sera 
stockée la clef privée. Et aussi savoir si on doit utiliser PAM, et comment.



> Le 19 juil. 2023 à 00:00, ajh-valmer  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.tar...@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 ?
> 

Re: Authentification ssh et PAM

[ajh-valmer]

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.tar...@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 ?