[HS] Logiciel libre pour sites web
La ville de Paris met à disposition un logiciel libre pour la céation de sites web. il y aurait 500 plugins pour l'adapter à ses besoins. https://lutece.paris.fr/fr/ En pièce jointe l'article de presse en PDF Bonne découverte Cassis 20230718-logiciels-libres-et-mutualisation-quand-paris-montre-lexemple.pdf Description: Adobe PDF document
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
> 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
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
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: Fwd: Authentification ssh et PAM
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
Fwd: Authentification ssh et PAM
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 > 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 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
Re: Authentification ssh et PAM
> 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
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
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
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
> 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: [Résolu] configurer client mail par défaut
Le 2023-07-19 10:52, benoit a écrit : Le mercredi 19 juillet 2023 à 10:23, Sébastien NOBILI a écrit : Les applications graphiques n'utilisent pas le système d'alternatives. Je voudrais toutefois nuancer que c'est bien le cas pour le choix du navigateur internet(x-www-browser) et du terminal émulateur sous X(x-terminal-emulator). update-alternatives --get-selections --8<-- x-terminal-emulatorauto /usr/bin/terminator x-www-browser auto /usr/bin/brave-browser-stable En effet, merci pour la nuance :) Sébastien
Re: Problème de Hotspot Wi-Fi
Pardon pour la pollution Mais voyez-vous mon poste original? J'ai l'impression qu'il n'est pas passé sur la liste.
[Résolu] configurer client mail par défaut
xdg-mime default org.gnome.Evolution.desktop 'x-scheme-handler/mailto' -- Benoît
[HS] avenir des NUC Intel
C'est tout-à-fait hors-sujet mais comme les NUC Intel ont déjà été évoqués sur cette liste par leurs utilisateurs comme des solutions intéressantes dans certains contextes, je transmets l'info: Il y a quelques jours Intel officialisait sa décision d'arrêter cette ligne de produits. Intel vient de passer les bases d'un accord avec Asus pour la reprise et la continuation de celle-ci (en anglais, Phoronix): https://www.phoronix.com/news/ASUS-Taking-Over-Intel-NUCs
Re: Problème de Hotspot Wi-Fi
test ?
[Résolu] configurer client mail par défaut
Le mercredi 19 juillet 2023 à 10:23, Sébastien NOBILI a écrit : > Bonjour, > > Le 2023-07-19 10:11, benoit a écrit : > > > Dans Firefox c'est emacs par défaut dans : Général → Applications > > → mailto > > > > Je n’ai pas trouvé la bonne alternative pour configurer ça avec > > update-alternatives –get-selections. > > > Les applications graphiques n'utilisent pas le système d'alternatives. Je voudrais toutefois nuancer que c'est bien le cas pour le choix du navigateur internet(x-www-browser) et du terminal émulateur sous X(x-terminal-emulator). update-alternatives --get-selections --8<-- x-terminal-emulatorauto /usr/bin/terminator x-www-browser auto /usr/bin/brave-browser-stable > Ça se passe du côté de XDG. En l'occurrence pour le mail, c'est la > commande xdg-e-mail [1] qui est lancée. > > > Comment configurer le client mail par défaut ?Merci d'avance > > > Pour reconfigurer ça, tu peux t'inspirer de cette réponse : > > https://superuser.com/a/1606443 > > Sébastien > > 1: https://manpages.debian.org/bookworm/xdg-utils/xdg-email.1.en.html Merci pour ta réponse simple et limpide ! Problème résolu -- Benoît
Re: configurer client mail par défaut
Bonjour, Le 2023-07-19 10:11, benoit a écrit : Dans Firefox c'est emacs par défaut dans : Général → Applications → mailto Je n’ai pas trouvé la bonne alternative pour configurer ça avec update-alternatives –get-selections. Les applications graphiques n'utilisent pas le système d'alternatives. Ça se passe du côté de XDG. En l'occurrence pour le mail, c'est la commande xdg-e-mail [1] qui est lancée. Comment configurer le client mail par défaut ?Merci d'avance Pour reconfigurer ça, tu peux t'inspirer de cette réponse : https://superuser.com/a/1606443 Sébastien 1: https://manpages.debian.org/bookworm/xdg-utils/xdg-email.1.en.html
configurer client mail par défaut
Bonjour, Dans Firefox c'est emacs par défaut dans : Général → Applications → mailto Je n’ai pas trouvé la bonne alternative pour configurer ça avec update-alternatives –get-selections. Comment configurer le client mail par défaut ? Merci d'avance -- Benoît Envoyé avec la messagerie sécurisée [Proton Mail.](https://proton.me/)
Re: Authentification ssh et PAM
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
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 ?
