Cédrix
1 line
41 KiB
JSON
1 line
41 KiB
JSON
[{"uuid":"104a8694-4268-4e0a-99c7-e7ecfd47af1e","slug":"auto-heberger-son-serveur-mail-en-2026","title":"Auto-héberger son serveur mail en 2026","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 08:35","created_at":"2026-05-12 08:38:14","updated_at":"2026-05-12 08:40:06","tags":[],"plain":"Survivre aux règles de Gmail, Outlook et consorts\r\nContexte — Cet article de Clubic (lien) rappelle une vérité technique : SMTP date de 1982, n'a aucune sécurité native, et toutes les \"rustines\" (SPF, DKIM, DMARC, MTA-STS, DANE) ont été conçues par Yahoo, Cisco, Microsoft, Google. Depuis février 2024 (Google) et mai 2025 (Microsoft), tout expéditeur dépassant 5000 mails/jour vers Gmail/Outlook doit configurer SPF + DKIM + DMARC, maintenir un taux de spam < 0,1 %, et fournir un lien de désinscription en un clic.\r\nMais même en dessous de 5000/jour, ces règles s'appliquent en pratique : sans elles, ton mail finit en spam ou est rejeté. Ce dossier décrit comment monter son propre serveur mail tout en passant à travers ces filtres.\r\n--\r\n\r\nSommaire\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n2. Prérequis techniques\r\n3. Architecture cible\r\n4. Choix du fournisseur et de l'IP\r\n5. Configuration DNS complète\r\n6. Installation du stack mail\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n9. PTR (reverse DNS) et HELO\r\n10. Warmup d'IP : la phase la plus délicate\r\n11. Postmaster Tools, SNDS, FBL\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n13. Anti-spam entrant et hygiène\r\n14. Monitoring, logs, alertes\r\n15. Que faire quand Gmail rejette quand même ?\r\n16. Checklist finale avant mise en prod\r\n17. Annexes : commandes utiles\r\n--\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n\r\nL'auto-hébergement mail est techniquement possible, mais c'est probablement le service le plus pénible à maintenir en 2026. Avant de te lancer, lis ça :\r\n\r\nCe qui marche bien en auto-hébergé :\r\nRecevoir du mail (presque tout le monde te livre).\r\nEnvoyer vers d'autres serveurs auto-hébergés ou pros bien configurés.\r\nGarder le contrôle sur tes données, tes alias, tes domaines.\r\n\r\nCe qui est dur :\r\nEnvoyer vers Gmail / Outlook / Yahoo / iCloud sans atterrir en spam.\r\nSortir d'une blacklist une fois dedans.\r\nMaintenir un score de réputation IP correct sur la durée.\r\nSurvivre à un changement unilatéral des règles côté gros acteurs (cf. février 2024 et mai 2025).\r\n\r\nStratégie réaliste recommandée :\r\nRéception entrante : auto-hébergée à 100 %. Aucun risque, full contrôle.\r\nEnvoi sortant : deux options, selon ton volume et ton tolérance au risque.\r\nOption A — Pure auto-hébergée : tu envoies directement depuis ton serveur. Faisable, mais demande un warmup, une IP propre, et un suivi continu.\r\nOption B — Smart host sortant : tu envoies via un relais réputé (un autre de tes serveurs avec une IP qui a déjà sa réputation, ou un service type Mailjet/Sendgrid/SMTP2GO en bas volume gratuit). Tes mails sortent depuis l'IP du relais, qui a déjà sa réputation faite. C'est un compromis : tu perds une partie de la souveraineté technique, mais tu gagnes énormément en délivrabilité.\r\n\r\nLe reste du dossier suit l'option A — tout en t'expliquant comment basculer en B si nécessaire.\r\n--\r\n\r\n2. Prérequis techniques\r\nÉlément | Détail |\r\n---|---|\r\nDomaine | À toi, registrar peu importe, mais avec DNSSEC activable (cf. §8 pour DANE). |\r\nServeur | VPS ou dédié, 2 vCPU / 4 Go RAM minimum, Debian 12+ ou Ubuntu 24.04 LTS. |\r\nIP fixe v4 | Indispensable. IP \"résidentielle\" ou IP de datacenter récemment recyclée = exclues. |\r\nIP fixe v6 | Recommandée, mais désactivable si l'IPv6 du fournisseur est blacklistée. |\r\nPTR / reverse DNS | Modifiable par toi. Si l'hébergeur ne te le permet pas, change d'hébergeur. |\r\nPorts | 25, 465, 587, 993, 4190 ouverts sortants ET entrants. Le port 25 sortant est bloqué chez beaucoup d'hébergeurs grand public (OVH résidentiel, Free, etc.) : vérifie avant. |\r\nTLS | Certificat valide (Let's Encrypt suffit). |\r\n\r\nCompétences attendues : Linux en ligne de commande, DNS (champs A/AAAA/MX/TXT/SRV/CAA/TLSA), notion de TLS, lecture de logs et .\r\n--\r\n\r\n3. Architecture cible\r\n\r\nUn stack standard, éprouvé, en logiciels libres :\r\n\r\n\r\n\r\nComposants :\r\nPostfix : MTA. Reçoit, route, envoie le SMTP.\r\nDovecot : serveur IMAP/POP3, livraison locale (LMTP), authentification SASL pour Postfix, gestion Sieve (filtres).\r\nRspamd : antispam moderne, fait aussi la vérification SPF/DKIM/DMARC entrante, le greylisting, et — option recommandée — la signature DKIM sortante (en remplacement d'OpenDKIM).\r\nLet's Encrypt (certbot) : TLS.\r\n(Optionnel) Roundcube ou SnappyMail : webmail.\r\n\r\nAlternative tout-en-un : Mailcow ou Mailu, basés sur Docker, qui empaquètent tout ça avec une interface admin. Si tu préfères ne pas tout configurer à la main, c'est légitime — la majorité des règles DNS et de délivrabilité de ce dossier restent identiques.\r\n--\r\n\r\n4. Choix du fournisseur et de l'IP\r\n\r\nLe choix de l'hébergeur conditionne la moitié de ta délivrabilité. Avant de prendre un VPS :\r\n\r\n1. Le port 25 sortant est-il ouvert ? Beaucoup d'hébergeurs le bloquent par défaut pour limiter le spam (Hetzner l'ouvre sur demande, OVH l'ouvre selon le produit, Scaleway l'ouvre selon le compte). Pose la question au support avant de payer.\r\n2. Le PTR est-il configurable ? Si non, change.\r\n3. L'IP a-t-elle été utilisée par un spammeur ? Avant d'acheter le VPS, demande l'IP qu'on te donnera. Vérifie sur :\r\nmxtoolbox.com/blacklists.aspx\r\nmultirbl.valli.org\r\ntalosintelligence.com (Cisco)\r\nsenderscore.org\r\n \r\n Si l'IP est listée sur Spamhaus, Barracuda, SORBS, SpamCop, demande à l'hébergeur de te l'échanger ou prends un autre VPS. Une fois listée, tu vas y passer des semaines.\r\n4. Réputation du subnet (). Même si ton IP est propre, si le est pourri (beaucoup de spammeurs voisins), Gmail va te traiter avec méfiance. Vérifie sur senderscore.org en saisissant ton IP — le score du subnet apparaît.\r\n\r\nHébergeurs réputés corrects pour le mail : Hetzner, OVH (gamme dédiée, pas SoYouStart), Scaleway, Infomaniak (en VPS), Netcup. À éviter pour de l'envoi : DigitalOcean (subnets souvent grillés), Linode/Akamai (idem), AWS EC2 (le port 25 est limité par défaut, et la rate-limit est costaude).\r\n--\r\n\r\n5. Configuration DNS complète\r\n\r\nPour un domaine avec un serveur mail sur à l'IP (et en v6) :\r\n\r\n\r\n\r\nDétails dans les sections dédiées plus bas.\r\n\r\nÀ ne pas oublier : l'enregistrement PTR (reverse DNS) se configure chez ton hébergeur, pas dans ta zone DNS. Il doit pointer . C'est traité au §9.\r\n--\r\n\r\n6. Installation du stack mail\r\n\r\nSur Debian 12. Ce qui suit est volontairement condensé — pour une configuration ligne par ligne, suis le tutoriel de référence de Workaround.org qui est l'étalon depuis 20 ans.\r\n\r\n\r\n\r\nPostfix : configuration minimale-mais-saine\r\n\r\n\r\n\r\nDovecot, Rspamd\r\n\r\nCes composants demandent leurs propres fichiers de configuration. Renvoi explicite vers les tutos qui font autorité :\r\nWorkaround.org / ISPmail : https://workaround.org/ispmail/ — référence francophone et anglophone, mise à jour à chaque version Debian.\r\nRspamd quickstart : https://www.rspamd.com/doc/tutorials/quickstart.html\r\nDovecot wiki : https://doc.dovecot.org/\r\n\r\nSi tu veux gagner du temps, Mailcow () est aujourd'hui la solution clé-en-main la plus fiable.\r\n--\r\n\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n\r\nSans ces trois enregistrements correctement configurés, Gmail et Outlook rejetteront ou marqueront en spam la majorité de tes messages — peu importe ton volume.\r\n\r\nSPF (Sender Policy Framework)\r\n\r\nDéclare qui a le droit d'envoyer du mail pour ton domaine.\r\n: autorise les serveurs listés dans le MX du domaine.\r\n: rejet strict de tout le reste. Indispensable pour la réputation. Ne jamais utiliser (softfail) en prod : Gmail aujourd'hui considère comme un signal faible.\r\n\r\nSi tu envoies aussi via un relais externe (smart host) : ajoute son , ex. .\r\n\r\nLimite : un enregistrement SPF doit tenir en 10 lookups DNS maximum. Au-delà, il est invalide. Vérifie avec https://www.kitterman.com/spf/validate.html.\r\n\r\nDKIM (DomainKeys Identified Mail)\r\n\r\nSigne chaque mail sortant avec une clé privée. Le destinataire vérifie la signature via la clé publique publiée en DNS.\r\n\r\nGénération de la clé (Rspamd, sélecteur , clé 2048 bits) :\r\n\r\n\r\n\r\nLe fichier contient l'enregistrement DNS à publier :\r\n\r\n\r\n\r\nConfiguration Rspamd () :\r\n\r\n\r\n\r\nRecharge : .\r\n\r\nVérification : envoie un mail à check-auth@verifier.port25.com, tu reçois un rapport complet SPF/DKIM/DMARC en retour. Ou utilise https://www.mail-tester.com/ (note sur 10).\r\n\r\nDMARC (Domain-based Message Authentication, Reporting and Conformance)\r\n\r\nDit aux serveurs distants quoi faire en cas d'échec SPF/DKIM, et te renvoie des rapports sur ce qui passe et ce qui rate.\r\n: surveillance seule, à utiliser pendant 2-4 semaines en démarrage pour collecter les rapports sans pénaliser.\r\n: mise en spam des mails non authentifiés. Cible normale.\r\n: rejet pur. À atteindre en cible finale, après avoir vérifié 4 semaines de rapports propres.\r\n: adresse pour les rapports agrégés (quotidiens).\r\n: rapports forensiques (par message). Optionnel.\r\n: alignement strict — le domaine de signature DKIM et le domaine SPF doivent exactement correspondre au domaine .\r\n\r\nLecture des rapports DMARC : ils arrivent en XML, illisibles. Utilise un parseur :\r\nPostmark DMARC Monitoring (gratuit, agrège les rapports dans une UI).\r\nparsedmarc (auto-hébergeable, envoie dans Elasticsearch/Splunk/Grafana).\r\n--\r\n\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n\r\nCes standards sécurisent le transport entre serveurs (chiffrement TLS forcé). Gmail les regarde, Microsoft aussi. Pas obligatoires, mais ils boostent ta réputation.\r\n\r\nMTA-STS\r\n\r\nForce les serveurs distants à utiliser TLS pour t'envoyer des mails. Trois éléments :\r\n\r\n1. Enregistrement DNS TXT :\r\n\r\n\r\n2. Sous-domaine servant un fichier en HTTPS à :\r\n\r\n\r\n est la cible. En démarrage, mets pendant 1-2 semaines.\r\n\r\n3. Certificat TLS valide sur ce sous-domaine (déjà fait via certbot au §6).\r\n\r\nTLS-RPT\r\n\r\nDemande aux serveurs distants de t'envoyer des rapports en cas d'échec TLS.\r\n\r\n\r\n\r\nDANE (DNS-based Authentication of Named Entities)\r\n\r\nEncore plus solide que MTA-STS, mais nécessite DNSSEC activé sur ton domaine. Si ton registrar ne supporte pas DNSSEC, oublie DANE.\r\n\r\nDANE publie un hash du certificat TLS dans un enregistrement TLSA :\r\n\r\n\r\n\r\nOu plus simplement avec https://www.huque.com/bin/gentlsa :\r\n\r\n\r\n\r\nVérification globale de tout ton setup TLS+DANE : https://internet.nl/mail/ (excellent, recommandé).\r\n--\r\n\r\n9. PTR (reverse DNS) et HELO\r\n\r\nLe PTR est probablement la cause la plus fréquente de rejet par Gmail/Outlook chez les nouveaux auto-hébergés.\r\n\r\nRègle absolue : , et tout doit être un FQDN cohérent.\r\n\r\nConfigure le PTR dans le panneau de ton hébergeur (chez OVH : \"IP\" → \"Reverse DNS\") :\r\n\r\n\r\nVérifie :\r\n\r\n\r\nDans Postfix, et c'est ce qui est annoncé en HELO. Cohérence garantie.\r\n--\r\n\r\n10. Warmup d'IP : la phase la plus délicate\r\n\r\nUne IP neuve = pas de réputation = défiance maximale des gros acteurs. Tu ne peux pas envoyer 1000 mails le jour 1 sans te griller.\r\n\r\nPlan de warmup sur 4 à 6 semaines\r\nSemaine | Volume max/jour vers Gmail+Outlook | Volume max/jour total | Contenu |\r\n---|---|---|---|\r\n1 | 20-50 | 100 | Mails à toi-même, comptes test sur Gmail/Outlook/Yahoo. Réponds-y, marque \"non spam\" si en spam. |\r\n2 | 100 | 300 | Cercle proche qui sait répondre / interagir. |\r\n3 | 300 | 1000 | Élargissement progressif. |\r\n4 | 800 | 3000 | Ouvre aux usages normaux. |\r\n5+ | 2000+ | volume cible | Stable. |\r\n\r\nRègles d'or pendant le warmup :\r\nPas de mailing list, pas de notifs automatiques en masse. Privilégie des mails 1-à-1 conversationnels.\r\nDemande aux destinataires de répondre — un mail avec réponse a 100x le poids d'un mail ouvert silencieusement.\r\nAucun lien raccourci, aucun pixel de tracking, aucune image lourde.\r\nStop net si ton score Senderscore baisse ou si Gmail Postmaster Tools (cf. §11) montre du rouge.\r\n\r\nSi tu as un volume immédiat à envoyer\r\n\r\nBascule en option B (smart host) le temps du warmup, puis rapatrie progressivement en interne en répliquant les volumes ci-dessus.\r\n--\r\n\r\n11. Postmaster Tools, SNDS, FBL\r\n\r\nLes gros acteurs te donnent des dashboards dédiés. Inscris-toi à tous, dès la création du domaine.\r\nService | Acteur | Usage |\r\n---|---|---|\r\nGoogle Postmaster Tools | Gmail | Réputation IP+domaine, taux de spam, authentification, encryption. Indispensable. |\r\nMicrosoft SNDS | Outlook/Hotmail | Smart Network Data Services, qualité de l'IP. |\r\nMicrosoft JMRP | Outlook | Junk Mail Reporting Program, FBL Microsoft. |\r\nYahoo CFL | Yahoo | Complaint Feedback Loop. |\r\nValidity Sender Score | Indépendant | Score sur 100, à surveiller. |\r\n\r\nConfigure les feedback loops (FBL) : quand un destinataire clique \"spam\", tu reçois une notification. Ça te permet de désinscrire l'utilisateur avant qu'il ne dégrade ta réputation.\r\n--\r\n\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n\r\nExigence Google/Microsoft pour les expéditeurs en volume, mais à mettre en place dès le début même en bas volume.\r\n\r\nAjoute deux en-têtes à tous les mails non-strictement-personnels :\r\n\r\n\r\n\r\nL'URL HTTPS doit accepter une requête POST (pas seulement GET) avec dans le corps, et désinscrire immédiatement et silencieusement sans demander de confirmation.\r\n--\r\n\r\n13. Anti-spam entrant et hygiène\r\n\r\nUn serveur mail mal configuré côté entrée devient vite un relais de spam ou une cible. Configuration Rspamd minimale :\r\n\r\n\r\n\r\n\r\n\r\nActive aussi :\r\nVérification SPF/DKIM/DMARC entrante (par défaut activée dans Rspamd).\r\nRBL (Realtime Blackhole Lists) : Spamhaus ZEN, Barracuda. Attention à ne pas multiplier — 2 ou 3 RBL fiables suffisent.\r\nGreylisting : refuse temporairement les premiers contacts, ce qui élimine 80% du spam basique. Ne pas activer sur un domaine à fort volume transactionnel (gêne les notifs).\r\nBayes : laisse Rspamd apprendre via le dossier de Dovecot (signal / ).\r\n\r\nMises à jour : activé, redémarrage planifié, lecture des annonces sécu Postfix/Dovecot.\r\n--\r\n\r\n14. Monitoring, logs, alertes\r\n\r\nSans monitoring, tu découvres les problèmes par les utilisateurs. À mettre en place :\r\nLecture des logs : , , web UI de Rspamd sur .\r\nMétriques : exporter Postfix/Dovecot vers Prometheus + Grafana (, ).\r\nAlertes sur :\r\nFile d'attente Postfix > 50 messages ().\r\nScore Senderscore qui chute.\r\nApparition sur une RBL : surveillance automatisée par https://multirbl.valli.org/ ou via un script qui interroge plusieurs DNSBL en cron.\r\nÉchec TLS-RPT (rapport entrant signalant une connexion non chiffrée).\r\nRapports DMARC parsés régulièrement (cf. §7).\r\n--\r\n\r\n15. Que faire quand Gmail rejette quand même ?\r\n\r\nÇa arrive. Diagnostic dans l'ordre :\r\n\r\n1. Lis le code de rejet SMTP dans . Gmail renvoie des codes très explicites :\r\n→ contenu jugé spammy. Revois le contenu, ajoute du texte conversationnel, retire les liens douteux.\r\n→ tu as dépassé un seuil. Ralentis immédiatement, attends 24-48h, reprends doucement.\r\n→ ton DMARC ne passe pas. Revérifie SPF/DKIM/alignement.\r\n→ tu es sur une RBL. Va sur spamhaus.org/lookup/ pour vérifier et demander la sortie.\r\n2. Va dans Postmaster Tools (§11). Si \"IP reputation\" est rouge ou orange, regarde le contenu et le timing de tes envois récents.\r\n3. Test mail-tester : envoie à une adresse fournie par mail-tester.com, obtiens une note sur 10. Vise 10/10. Toute case manquante doit être corrigée.\r\n4. Sortie de blacklist : la plupart des RBL (Spamhaus, Barracuda) ont un formulaire de retrait. Spamhaus retire en quelques heures si tu corriges la cause. SORBS est plus lent. UCEPROTECT exige souvent de payer — ignore-la, peu de serveurs sérieux la consultent.\r\n5. Si rien ne marche, change d'IP. C'est parfois la seule issue. Demande à ton hébergeur une IP fraîche, refais un warmup.\r\n--\r\n\r\n16. Checklist finale avant mise en prod\r\n\r\nAvant d'envoyer le premier vrai mail :\r\n[ ] Domaine avec DNSSEC activé.\r\n[ ] IP testée sur 5+ blacklists, propre.\r\n[ ] Port 25 sortant ouvert et testé ().\r\n[ ] PTR configuré et cohérent avec le HELO.\r\n[ ] MX, A, AAAA, SPF, DKIM, DMARC publiés et validés via mxtoolbox.com.\r\n[ ] MTA-STS publié (mode au démarrage).\r\n[ ] TLS-RPT publié.\r\n[ ] DANE/TLSA publié (si DNSSEC OK).\r\n[ ] CAA publié.\r\n[ ] Test envoyé à : tout en .\r\n[ ] Test mail-tester.com : 10/10.\r\n[ ] Test internet.nl/mail/ : 100%.\r\n[ ] Inscription Postmaster Tools, SNDS, JMRP, Yahoo CFL.\r\n[ ] DMARC au démarrage, parser de rapports en place.\r\n[ ] List-Unsubscribe + List-Unsubscribe-Post implémentés.\r\n[ ] Plan de warmup affiché et respecté.\r\n[ ] Monitoring file d'attente + RBL en place.\r\n[ ] Backup chiffré des Maildir.\r\n\r\nAu bout de 4 semaines de rapports DMARC propres : passage à . Au bout de 8-12 semaines : .\r\n--\r\n\r\n17. Annexes : commandes utiles\r\n\r\n\r\n\r\nOutils web à mettre en favoris\r\nhttps://www.mail-tester.com/ — score sur 10\r\nhttps://internet.nl/mail/ — audit complet\r\nhttps://mxtoolbox.com/SuperTool.aspx — DNS, blacklists\r\nhttps://dmarcian.com/dmarc-inspector/ — vérif DMARC\r\nhttps://www.kitterman.com/spf/validate.html — vérif SPF\r\nhttps://postmaster.google.com/ — Google Postmaster\r\nhttps://senderscore.org/ — réputation IP\r\n\r\nDocumentation de référence\r\nISPmail / Workaround.org — https://workaround.org/ispmail/ — le tutoriel le plus complet et tenu à jour, par version Debian.\r\nMailcow docs — https://docs.mailcow.email/ — pour la version conteneurisée clé-en-main.\r\nPostfix officiel — https://www.postfix.org/documentation.html\r\nRspamd docs — https://www.rspamd.com/doc/\r\nRFCs essentielles** : 5321 (SMTP moderne), 7208 (SPF), 6376 (DKIM), 7489 (DMARC), 8461 (MTA-STS), 8460 (TLS-RPT), 7672 (DANE-SMTP), 8058 (One-Click Unsubscribe).\r\n--\r\n\r\nL'auto-hébergement mail en 2026 reste possible, mais c'est devenu un sport : les règles changent, les gros acteurs durcissent leurs critères, et l'écosystème pousse vers la centralisation. Si tu réussis le warmup et tiens 6 mois sans incident, tu as gagné — mais ne baisse pas la garde, un changement unilatéral de Google peut survenir à tout moment, comme en février 2024."},{"uuid":"7cf4eff3-2bab-4f2e-8982-247c89f7ca16","slug":"installer-webmin-l-outil-d-administration-en-mode-web","title":"Mettre en place un serveur Debian administrable avec Webmin","category":"linux","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-13 11:57","created_at":"2025-11-13 11:57:05","updated_at":"2026-05-12 10:48:26","tags":[],"plain":"Quand on monte un nouveau serveur, les premières heures sont toujours les mêmes : on durcit la machine, on crée un utilisateur correct, on coupe ce qui traîne, et on met en place de quoi l'administrer sans avoir à ouvrir un terminal pour chaque détail. Cet article décrit la procédure que j'utilise sur mes Debian fraîches : préparation via mes scripts, installation de Webmin, et activation de pour ne laisser passer que ce qui doit l'être. L'idée n'est pas de transformer le serveur en sapin de Noël, mais d'avoir une base saine sur laquelle bâtir, qu'il s'agisse d'expérimenter dans un LXC ou de préparer une VM destinée à recevoir une vraie charge. Étape 1 — Préparer la machine Sur une Debian neuve, on commence par récupérer un petit script qui en télécharge d'autres. C'est juste un point d'entrée : il va chercher dans mon dépôt Forgejo un ensemble de scripts d'initialisation que je maintiens à jour. À ce stade, un dossier apparaît à côté du script. C'est là que se trouve le vrai travail : fait ce qu'on a tous fini par écrire un jour : mise à jour des paquets, installation des outils de base, création d'un utilisateur non-root avec les bons droits sudo, durcissement minimal de SSH. Rien de magique, mais c'est répétable et c'est ce qui compte quand on provisionne souvent. Important : une fois le script terminé, il faut se déconnecter de la session et se reconnecter avec l'utilisateur que le script vient de créer. Tout ce qui suit se fait avec cet utilisateur, en passant par quand nécessaire. Continuer en root est une mauvaise habitude qui finit toujours par se payer. Étape 2 — Installer Webmin Webmin est une interface web d'administration système. Pour quelqu'un qui débute, c'est une porte d'entrée appréciable : on voit les services qui tournent, les utilisateurs, les paquets installés, les logs, le tout depuis un navigateur. Pour quelqu'un d'expérimenté, c'est un complément pratique quand on veut donner un accès limité à un collègue moins à l'aise en ligne de commande. Webmin fournit son propre script pour configurer le dépôt apt : Ce script ajoute le dépôt officiel Webmin à la liste des sources apt et importe la clé GPG associée. Une fois fait, l'installation devient une commande apt classique : Petite précision sur les deux paquets : Webmin sert à l'administration système (root ou utilisateur sudo), Usermin est sa version pour les utilisateurs standards, qui leur permet de gérer leur propre compte, leurs mails, leurs fichiers, sans toucher au système. Sur une machine mono-utilisateur, on peut se passer d'Usermin, mais l'installer maintenant coûte trois mégaoctets et évite d'y revenir plus tard. Étape 3 — Se connecter à l'interface Webmin écoute par défaut sur le port 10000 en HTTPS. Depuis un navigateur : est à remplacer par l'adresse de la machine. Le navigateur va râler à propos du certificat — c'est normal, Webmin génère un certificat auto-signé à l'installation. On peut accepter l'avertissement pour l'instant ; si la machine est destinée à un usage durable, on remplacera ça plus tard par un vrai certificat (Let's Encrypt via un reverse proxy, par exemple). Pour la connexion, on utilise les identifiants Linux de l'utilisateur sudo, pas un compte spécifique à Webmin. C'est l'utilisateur que a créé à l'étape 1. Webmin s'appuie sur PAM, donc tout compte système autorisé à se connecter peut potentiellement entrer — d'où l'importance de l'étape suivante. Étape 4 — Activer le pare-feu Une machine accessible sur internet sans pare-feu, c'est une question de temps avant les premiers ennuis. Sur Debian, je préfère à ou à la configuration brute de : la notion de zones est pratique, la syntaxe se retient, et l'intégration avec Webmin est correcte. Installation et activation : rend le service persistant au redémarrage, le lance immédiatement. Vérification : Le retour attendu est . Si c'est autre chose, permet de comprendre ce qui coince — c'est souvent un conflit avec un autre service de filtrage déjà en place. À ce stade, le pare-feu tourne mais avec une configuration par défaut qui, selon la zone active, peut bloquer Webmin. Il faut donc explicitement autoriser le port 10000 : Le écrit la règle dans la configuration ; sans ça, elle disparaît au prochain redémarrage. Le recharge la configuration pour que la règle prenne effet immédiatement. C'est l'erreur classique : on ajoute une règle, on continue à ne pas pouvoir se connecter, on perd dix minutes avant de se rappeler du . Pour aller plus loin Une fois cette base en place, plusieurs directions s'offrent selon le rôle de la machine. Si elle est destinée à héberger un service web public, l'étape logique suivante consiste à placer Webmin derrière un reverse proxy plutôt que de l'exposer directement sur le port 10000. Le port 10000 est alors fermé vers l'extérieur, et l'interface devient accessible via un sous-domaine en HTTPS avec un vrai certificat. C'est plus propre, plus sûr, et ça évite l'avertissement de certificat à chaque connexion. Si la machine est un serveur d'applications, autant profiter du fait que est en place pour réfléchir aux ports en amont. Mieux vaut décider tout de suite quelles applications écoutent où, plutôt que d'empiler les au fil de l'eau et de finir avec une configuration que plus personne ne comprend. Et dans tous les cas, garder une trace écrite des choix faits : quels ports ouverts, quel utilisateur sudo, quelle convention de nommage. Un fichier à la racine du home de l'admin, peu importe le support — l'important c'est que dans six mois, on puisse retrouver le fil sans avoir à tout rétro-ingénierer."},{"uuid":"d9006eec-fc78-4e2f-9470-b0d173c68b7c","slug":"installer-mqtt-broker-mosquitto-linux","title":"Installer Mqtt Broker Mosquitto Linux","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-18 07:56:13","created_at":"2023-02-18 07:56:13","updated_at":"2023-02-18 07:56:13","tags":[],"plain":"REDIRECT>informatique:applications:mosquitto"},{"uuid":"5510b12a-d647-4b1a-90ba-d421a4927ff7","slug":"configurer-un-client-oauth-2-0-dans-keycloak-guide-complet","title":"Configurer un client OAuth 2.0 / OIDC dans Keycloak","category":"informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-05-16 23:33","created_at":"2025-05-16 23:33:31","updated_at":"2026-05-12 20:39:53","tags":[],"plain":"Keycloak est une solution open source de gestion des identités et des accès (IAM). Cet article décrit la configuration d'un client OAuth 2.0 / OpenID Connect dans Keycloak, en détaillant les options importantes et en montrant comment restreindre l'accès aux utilisateurs ou groupes autorisés.\r\nNote de version. L'interface d'administration a été refondue à partir de Keycloak 19. La notion d'Access Type ( / / ) a disparu au profit des toggles Client authentication et Authorization. Ce guide suit l'UI actuelle (Keycloak 24+).\r\n--\r\n\r\n1. Prérequis\r\nUne instance Keycloak fonctionnelle (version 24 ou supérieure recommandée).\r\nDes droits d'administration sur un realm.\r\nUne application destinée à s'authentifier via OAuth 2.0 / OIDC.\r\nTLS activé sur Keycloak et sur l'application cliente (obligatoire en production).\r\n--\r\n\r\n2. Qu'est-ce qu'un client dans Keycloak ?\r\n\r\nDans Keycloak, un client représente une application ou un service qui interagit avec le serveur d'authentification, soit pour authentifier des utilisateurs, soit pour obtenir des informations sur eux, soit pour protéger ses propres ressources. Il peut s'agir d'une application web, d'une API, d'une application mobile, d'un service interne ou d'un partenaire tiers.\r\n\r\nChaque client est rattaché à un realm (l'espace logique d'authentification) et identifié par un unique. Cet identifiant est transmis lors de toute demande d'authentification ou d'obtention de jeton.\r\n\r\nLa configuration d'un client définit notamment :\r\nles flux OAuth 2.0 autorisés (, , etc.) ;\r\nla capacité ou non du client à conserver un secret (client confidentiel vs public) ;\r\nles URI de redirection acceptées et les origines CORS ;\r\nla durée de vie des jetons et la composition des claims (mappers) ;\r\nles politiques d'autorisation associées (rôles, groupes, attributs).\r\n--\r\n\r\n3. Création du client\r\n\r\n1. Se connecter à la Keycloak Admin Console.\r\n2. Sélectionner le realm cible.\r\n3. Menu Clients > Create client.\r\n\r\nÉtape « General settings »\r\nChamp | Valeur recommandée | Description |\r\n------------------ | ----------------------------------- | ---------------------------------------------------------------------------- |\r\nClient type | | Protocole utilisé. Choisir uniquement pour des intégrations SAML 2.0. |\r\nClient ID | | Identifiant unique du client dans le realm. Apparaît dans les jetons (). |\r\nName | | Libellé d'affichage (facultatif, peut être localisé). |\r\nDescription | Texte libre | Aide à la maintenance. |\r\n\r\nÉtape « Capability config »\r\nToggle | Valeur recommandée | Détail |\r\n------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------ |\r\nClient authentication | pour un backend, pour un SPA | rend le client confidentiel (un secret est généré). rend le client public. |\r\nAuthorization | | À activer uniquement si l'on souhaite utiliser le moteur d'autorisations fine (RBAC/ABAC) de Keycloak. |\r\nStandard flow | | Active le flux Authorization Code, à utiliser systématiquement. |\r\nDirect access grants | | Flux — déconseillé par OAuth 2.1, à n'utiliser que pour des outils internes legacy. |\r\nImplicit flow | | Déprécié par OAuth 2.1, ne pas activer. |\r\nService accounts roles | si clientcredentials | Permet au client de récupérer un jeton pour son propre compte (machine-to-machine). |\r\nOAuth 2.0 Device Auth Grant | (sauf besoin spécifique) | Pour les appareils sans navigateur (TV, CLI sans IHM locale). |\r\nOIDC CIBA Grant | (sauf besoin spécifique) | Authentification déportée (canal hors-bande). |\r\n\r\nÉtape « Login settings »\r\nChamp | Exemple | Description |\r\n----------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------- |\r\nRoot URL | | URL de base de l'application. Permet d'utiliser des chemins relatifs dans les champs suivants. |\r\nHome URL | | Page par défaut après login. |\r\nValid redirect URIs | | URI exactes autorisées pour la redirection après authentification. Éviter les wildcards larges. |\r\nValid post logout redirect URIs | | URI autorisées pour la redirection après déconnexion (RP-Initiated Logout). |\r\nWeb origins | | Origines CORS autorisées. La valeur reprend automatiquement les redirect URIs ; est à proscrire. |\r\nAdmin URL | | Utilisé pour les notifications backchannel (logout global, push not-before). |\r\nBonne pratique. Les redirect URIs doivent être en en production (sauf pour le développement). Spécifier des chemins aussi précis que possible plutôt qu'un wildcard .\r\n--\r\n\r\n4. Authentification du client (Credentials)\r\n\r\nL'onglet Credentials n'apparaît que si Client authentication est sur . Plusieurs méthodes sont disponibles :\r\nMéthode | Usage |\r\n-------------------------------- | ---------------------------------------------------------------------- |\r\nClient Id and Secret | Secret partagé classique. À stocker dans un coffre-fort (Vault, env vars chiffrées). |\r\nSigned JWT | Le client signe un JWT d'assertion avec sa clé privée. Plus sûr qu'un secret. |\r\nSigned JWT with Client Secret | Variante symétrique (HMAC). |\r\nX.509 Certificate | mTLS — recommandé pour les contextes à forte exigence (FAPI, banque). |\r\nImportant. Le secret ne doit jamais être commité dans Git ni embarqué dans un binaire distribué. Pour un projet où les secrets vivent dans , ne commiter que .\r\n--\r\n\r\n5. Types de clients\r\n\r\nDepuis Keycloak 19, le « type » est déduit de la combinaison des toggles. La terminologie OAuth reste utile :\r\nType | Configuration Keycloak | Cas d'usage |\r\n--------------- | ------------------------------------------------------------------- | ------------------------------------------------------------ |\r\nConfidentiel | | Backend serveur (PHP, Node, Java…), BFF, service-to-service. |\r\nPublic | + + PKCE | SPA (React, Vue, Angular), application mobile, CLI native. |\r\nService account | + | Communication machine-to-machine (). |\r\n\r\nLe type « bearer-only » a été retiré : pour une API qui se contente de valider des jetons sans déclencher d'authentification, créer un client confidentiel et n'activer aucun flux.\r\n--\r\n\r\n6. PKCE — recommandé pour tous les clients\r\n\r\nPKCE (Proof Key for Code Exchange, RFC 7636) protège le flux Authorization Code contre l'interception du code d'autorisation. Conçu initialement pour les clients publics, il est aujourd'hui recommandé pour tous les clients, y compris confidentiels, et obligatoire dans OAuth 2.1.\r\n\r\nActivation dans Advanced > Proof Key for Code Exchange Code Challenge Method > .\r\nNe jamais utiliser ; est la seule valeur acceptable.\r\n--\r\n\r\n7. Restreindre l'accès aux utilisateurs ou groupes\r\n\r\nPar défaut, tout utilisateur du realm peut se connecter via n'importe quel client. Deux approches permettent de restreindre cet accès.\r\n\r\nApproche 1 — Authentification basée sur les rôles (simple)\r\n\r\n1. Créer un rôle client dédié, par exemple , dans l'onglet Roles du client.\r\n2. Assigner ce rôle aux utilisateurs ou groupes autorisés (Users > user > Role mapping, ou Groups > group > Role mapping).\r\n3. Dans Authentication > Flows, ajouter une exécution au flux Browser, configurée avec le rôle requis et .\r\n\r\nCette méthode bloque l'authentification elle-même : un utilisateur sans le rôle ne pourra pas se connecter au client.\r\n\r\nApproche 2 — Authorization Services (granulaire)\r\n\r\nÀ utiliser pour gérer des permissions plus fines (ressources, scopes, conditions).\r\n\r\n1. Activer Authorization sur le client.\r\n2. Onglet Authorization > Policies > créer une Group Policy ou Role Policy listant les utilisateurs/groupes autorisés.\r\n3. Onglet Permissions > créer une Scope-Based Permission ou Resource-Based Permission liée à la policy.\r\n4. Côté application, utiliser l'endpoint UMA ou l'adaptateur Keycloak pour évaluer les permissions.\r\n\r\nApproche 3 — Limiter le client scope « roles »\r\n\r\nDans Client scopes > > Scope, désactiver Full scope allowed et n'autoriser que les rôles pertinents. Cela réduit la taille des jetons et limite ce que le client peut « voir » des rôles utilisateurs.\r\n--\r\n\r\n8. Client scopes et mappers\r\n\r\nLes client scopes déterminent les claims présents dans les jetons ( et ).\r\nLes scopes Default sont systématiquement ajoutés à chaque jeton.\r\nLes scopes Optional ne sont ajoutés que si l'application les demande via le paramètre lors de l'authentification.\r\n\r\nPour exposer les groupes d'un utilisateur dans le token :\r\n\r\n1. Créer un client scope (ou réutiliser celui existant).\r\n2. Ajouter un mapper de type Group Membership :\r\nToken Claim Name : \r\nFull group path : (sauf besoin d'arborescence)\r\nAdd to ID token / Access token / Userinfo : selon l'usage.\r\n3. Attacher le scope au client (Default ou Optional).\r\n--\r\n\r\n9. Réglages avancés à connaître\r\nSection | Réglage | Recommandation |\r\n---------------------------------- | -------------------------------- | ---------------------------------------------------------------- |\r\nAdvanced > Fine grain OpenID Connect configuration | | (par défaut) ou pour FAPI. |\r\nAdvanced > Advanced settings | | . |\r\nAdvanced > Advanced settings | | sauf si l'application implémente correctement la spec OIDC Front-Channel Logout. |\r\nAdvanced > Advanced settings | | Renseigner pour une déconnexion globale propre. |\r\nAdvanced > Token Lifespan | | Court (5–15 min). Le refresh token prend le relais. |\r\nSessions | | Aligner sur la politique de session de l'organisation. |\r\n\r\nPour appliquer automatiquement un ensemble cohérent de règles, utiliser les Client Policies du realm (profils pré-définis et ).\r\n--\r\n\r\n10. Checklist de sécurité\r\n[ ] pour tout client qui peut conserver un secret.\r\n[ ] PKCE activé.\r\n[ ] Implicit flow et Direct access grants désactivés.\r\n[ ] Redirect URIs en et sans wildcard inutile.\r\n[ ] Web origins explicites (pas de ).\r\n[ ] Secret stocké dans un coffre-fort, jamais commité.\r\n[ ] Access token court (≤ 15 min) et refresh token rotatif.\r\n[ ] Accès restreint via rôle dédié ou Authorization Services.\r\n[ ] Full scope allowed désactivé si les rôles transportés doivent être limités.\r\n[ ] Logout backchannel ou front-channel configuré.\r\n--\r\n\r\nConclusion\r\n\r\nLa configuration d'un client OAuth 2.0 dans Keycloak repose sur quelques choix structurants — confidentiel ou public, flux activés, PKCE, restriction d'accès — qui ont chacun des implications de sécurité fortes. S'aligner sur OAuth 2.1 (PKCE systématique, pas d'implicit flow, pas de password grant) et utiliser les Client Policies** pour appliquer ces règles à l'échelle du realm évite la plupart des configurations à risque."},{"uuid":"b2273ad3-797f-4ec6-905b-c7d58c0c33d3","slug":"installation-postgres-client-17-debian-ubuntu","title":"Installation d'un client postgre SQL 17 sur une distribution basée sur Debian/Ubuntu","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-02-09 09:18:30","created_at":"2025-02-09 09:18:30","updated_at":"2025-02-09 09:18:30","tags":[],"plain":"L'objectif de cet article est d'expliquer pas à pas l'installation du client PostgreSQL version 17 () sur une distribution Linux basée sur Debian ou Ubuntu. Ce guide s'adresse aux développeurs et administrateurs système souhaitant interagir avec une base de données PostgreSQL en utilisant uniquement le client.\n-- Pré-requis\nAvant de commencer, assurez-vous que :\n1. Vous avez les privilèges administrateur (accès ).\n1. Votre système est à jour avec les derniers correctifs de sécurité.\n-- Étapes d'installation\n1. Créer le répertoire pour le dépôt PostgreSQL\nLe premier pas consiste à créer le répertoire qui contiendra la clé de signature du dépôt PostgreSQL. Cela garantit la vérification de l'authenticité des paquets téléchargés. 2. Télécharger et ajouter la clé GPG\nLa clé GPG du dépôt PostgreSQL doit être téléchargée et installée pour valider les paquets téléchargés. Utilisez la commande suivante :\n⚠️ Astuce : Assurez-vous que la connexion Internet est active pour télécharger la clé depuis le site officiel de PostgreSQL. 3. Ajouter le dépôt PostgreSQL au gestionnaire de paquets\nAjoutez le dépôt PostgreSQL approprié à votre fichier de sources APT. La commande suivante le fait automatiquement, en détectant la version de votre système () : Cette ligne configure le fichier de sources pour qu'il utilise le dépôt officiel PostgreSQL. 4. Mettre à jour la liste des paquets\nMettez à jour la liste des paquets disponibles sur votre système avec la commande suivante : 5. Installer le client PostgreSQL version 17\nPour installer le client PostgreSQL version 17, exécutez simplement :\nNote : Le permet d'automatiser l'acceptation des invites lors de l'installation.\n-- Vérification de l'installation\nPour vérifier que le client PostgreSQL 17 est correctement installé, utilisez la commande suivante : La sortie doit indiquer la version 17. Par exemple :\n-- Conclusion\nVous avez maintenant installé avec succès sur votre système. Vous pouvez l'utiliser pour interagir avec n'importe quel serveur PostgreSQL. Pour des commandes comme la connexion à une base de données distante, utilisez : N'hésitez pas à consulter la documentation officielle de PostgreSQL pour approfondir vos connaissances."}] |