[{"article":{"uuid":"46644fd8-568b-440a-8db4-5e8b24cade8c","slug":"srv","title":"/srv","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-08-20 06:56:31","created_at":"2023-08-20 06:56:31","updated_at":"2023-08-20 06:56:31","plain":"Le répertoire /srv est défini dans le FHS (Filesystem Hierarchy Standard) pour stocker les données de service spécifiques à un système. Le but principal de spécifier ceci est que les utilisateurs puissent trouver l'emplacement des fichiers de données pour un service particulier, et que les services qui nécessitent un seul arbre pour les données en lecture seule, les données en écriture et les scripts (comme les scripts CGI) puissent être raisonnablement placés. Les données qui n'intéressent qu'un utilisateur spécifique doivent être placées dans le répertoire personnel de cet utilisateur. Si la structure de répertoire et de fichier des données n'est pas exposée aux consommateurs, elle doit être placée dans . La méthodologie utilisée pour nommer les sous-répertoires de  n'est pas spécifiée, car il n'existe actuellement aucun consensus sur la manière de le faire. Une méthode pour structurer les données sous  est par protocole, par exemple ftp, rsync, www et cvs. Sur de grands systèmes, il peut être utile de structurer  en fonction du contexte administratif, comme , , etc. Cette configuration variera d'un hôte à l'autre. Par conséquent, aucun programme ne doit compter sur une structure spécifique de sous-répertoire de  existant ou sur le fait que les données sont nécessairement stockées dans . Cependant,  devrait toujours exister sur les systèmes conformes à la norme FHS et devrait être utilisé comme emplacement par défaut pour de telles données. Les distributions doivent veiller à ne pas supprimer les fichiers placés localement dans ces répertoires sans l'autorisation de l'administrateur."},"score":7,"snippet":"Le répertoire /<mark>srv</mark> est défini dans le FHS (Filesystem Hierarchy Standard) pour stocker les données de service spécifiques à un système. Le but principal de spécifier ceci est que les utilisateurs puissent trouver l&#039;empla…","tier":1},{"article":{"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","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."},"score":1,"snippet":"…ues : Linux en ligne de commande, DNS (champs A/AAAA/MX/TXT/<mark>SRV</mark>/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\nPostf…","tier":2},{"article":{"uuid":"e0b26900-54db-49c8-9fb7-2fe3a84659b5","slug":"dossiers-remarquables","title":"200 · Répertoires et fichiers remarquables sous Linux","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-08-20 06:58:15","created_at":"2023-08-20 06:58:15","updated_at":"2023-08-20 06:58:15","plain":"La structure de répertoires pour les systèmes d'exploitation Linux et Unix est définit par le standard FHS (Filesystem Hierarchy Standard). Il a pour but de fournir une structure de répertoires pour les différents types de fichiers commune pour toutes les distributions Linux et Unix, afin de rendre les systèmes d'exploitation plus portables et plus faciles à utiliser. Il décrit également les règles de nommage des fichiers et des répertoires, ainsi que les conventions pour les fichiers de configuration et les fichiers de données. La structure de répertoire décrite par le FHS est divisée en plusieurs sections principales :\n/ : la racine de tous les répertoires Depuis le répertoire racine, vous trouverez les répertoires suivants :\n/home : contient les répertoires des utilisateurs,\n/bin : contient les commandes couramment utilisées,\n/boot : contient les fichiers nécessaires pour démarrer le système d'exploitation,\n/dev : contient des fichiers de périphériques,\n/etc : contient les fichiers de configuration,\n/lib : contient les bibliothèques de système et bibliothèques partagées,\n/media : contient des sous-dossiers pour les périphériques de stockage amovibles,\n/mnt : contient des sous-dossiers pour monter des systèmes de fichiers externes,\n/opt : contient des logiciels tiers ou des applications qui ne font pas partie des paquets de distribution standard,\n/run : contient des informations sur les processus en cours d'exécution et les périphériques connectés,\n/sbin : contient les commandes pour les administrateurs système. Peut-être remplacé par .\n/srv : contient les données de service spécifiques,\n/tmp : contient des fichiers temporaires qui sont utilisés par les programmes en cours d'exécution. Peut être remplacer par  ou .\n/usr : contient les programmes, les documents et les données utilisateur qui sont utilisés par tous les utilisateurs du système,\n/var : contient les fichiers qui peuvent changer pendant l'exécution du système. Le respect de cette structure de répertoires est important car cela permet d'éviter les conflits de nom, de faciliter la maintenance des systèmes, et de rendre les systèmes d'exploitation plus portables entre les différentes distributions. Répertoires et fichiers remarquables\nIl existe de nombreux répertoires remarquables dans une installation de Linux Fedora, voici quelques exemples. Dans le dossier personnel\nLe dossier personnel (ou répertoire de l'utilisateur) est généralement situé dans le répertoire  sur un système Linux. Le nom du répertoire de l'utilisateur est généralement le même que le nom d'utilisateur, par exemple :  pour un utilisateur nommé \"john\". Le répertoire de l'utilisateur en cours est représenté par le symbole .  Ce répertoire contient généralement des sous-répertoires pour les documents, les images, les musiques, les vidéos et les téléchargements, ainsi que des fichiers de configuration pour les différents programmes utilisés par l'utilisateur. Il est également utilisé comme un espace de travail pour les fichiers et les projets de l'utilisateur. Les utilisateurs ont généralement des autorisations en écriture sur ce répertoire, ce qui leur permet de créer, de supprimer et de modifier les fichiers et dossiers qu'il contient. Cependant, les autres utilisateurs ou les utilisateurs qui se connectent en tant qu'invité n'ont généralement pas accès à ce répertoire. Il existe plusieurs fichiers et répertoires remarquables dans le répertoire personnel d'un utilisateur sur un système Linux, voici quelques exemples :"},"score":1,"snippet":"…pour les administrateurs système. Peut-être remplacé par .\n/<mark>srv</mark> : contient les données de service spécifiques,\n/tmp : contient des fichiers temporaires qui sont utilisés par les programmes en cours d&#039;exécution. Peut être…","tier":2},{"article":{"uuid":"a59e2c3f-2385-4187-ba30-3c753959debf","slug":"configurer-autodiscover","title":"Configurer Autodiscover et Autoconfig","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 16:12:17","created_at":"2023-02-09 16:12:17","updated_at":"2023-02-09 16:12:17","plain":"DNS\n  autodiscover.tcp.yourdomain.com. 3600 IN SRV  10 10 443 mail.yourmx.com. Autodiscover pour Outlook Directives Apache Certificat SSL\nRemember to get a SIGNED SSL Cert. Autoconfig pour Thunderbird"},"score":1,"snippet":"DNS\n  autodiscover.tcp.yourdomain.com. 3600 IN <mark>SRV</mark>  10 10 443 mail.yourmx.com. Autodiscover pour Outlook Directives Apache Certificat SSL\nRemember to get a SIGNED SSL Cert. Autoconfig pour Thunderbird","tier":2},{"article":{"uuid":"b7647f3d-0c0a-46ef-815a-cb56e1e95aae","slug":"comment-casser-les-pattes-d-un-etudiant-plein-d-enthousiasme","title":"Comment casser les pattes d’un étudiant plein d’enthousiasme","category":"réflexion","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-04 21:25:49","created_at":"2025-11-04 21:25:49","updated_at":"2025-11-04 21:25:49","plain":"Chronique d’une mise à l’épreuve LinkedInienne\r\n\r\nIl y a sur LinkedIn de petites scènes de théâtre.\r\nDes instants où la fraîcheur, la naïveté et la passion d’un étudiant viennent se frotter à la rigueur — parfois au cynisme — du monde professionnel.\r\n\r\nCette semaine, le héros s’appelle Nathan Lempereur.\r\nÉtudiant en BTS SIO SISR, passionné d’informatique, il publie fièrement :\r\n« Sortie de SrvTools 1.0 !!\r\nJ’ai conçu un outil pour simplifier l’installation et la configuration de serveurs Linux. »\r\n\r\nUn projet open-source, rédigé en Bash, pensé pour aider les débutants et automatiser des tâches.\r\nUn travail concret, fait avec le cœur et la motivation.\r\nBref : le genre de post rafraîchissant qu’on aimerait voir plus souvent.\r\n\r\nMais voilà : LinkedIn n’est pas toujours tendre avec les enthousiastes.\r\nEt la plateforme adore rappeler que le monde professionnel, lui, ne s’émerveille pas — il évalue, dissèque, critique.\r\n--\r\n\r\nActe I – L’innocence du créateur\r\n\r\nNathan partage son outil avec sincérité.\r\nIl détaille son script, ses fonctions, la compatibilité, la licence.\r\nIl répond à tous, poliment, curieusement, avec ses mots à lui.\r\n\r\nSon ton n’est pas celui d’un expert, mais celui de quelqu’un qui ose.\r\nEt rien que pour ça, il méritait des applaudissements.\r\n\r\nMais sur LinkedIn, le tonnerre vient souvent d’ailleurs.\r\n--\r\n\r\nActe II – L’entrée des gardiens du temple\r\n\r\nLe premier commentaire bienveillant arrive, sous la forme d’un « bon boulot, mais ».\r\nToujours ce petit mais, fidèle compagnon des compliments à moitié avalés.\r\n« Bon boulot ! Effectivement, la compatibilité avec d’autres systèmes serait la bienvenue. »\r\n\r\nUn conseil pertinent, certes.\r\nMais déjà, l’équilibre se rompt : Nathan ne soumettait pas une RFC, il partageait sa fierté.\r\n\r\nPuis vient le classique :\r\n« Vous connaissez Ansible ? »\r\n\r\nSous-entendu : ton outil, c’est mignon, mais ça existe déjà — et en mieux, depuis dix ans.\r\nEt quand Nathan répond humblement qu’il ne connaît pas Ansible, on sent presque la salle soupirer.\r\nOh, le pauvre, il ne connaît pas Ansible.\r\n\r\nPourtant, il reste poli, à l’écoute, curieux.\r\nMais la leçon LinkedInienne est lancée : tu ne peux pas simplement être heureux d’avoir fait quelque chose — il faut défendre son utilité devant un jury invisible.\r\n--\r\n\r\nActe III – Les coups de pinceau du réalisme\r\n\r\nD’autres s’invitent dans la discussion.\r\nLes plus pédagogues demandent :\r\n« Comment comptes-tu maintenir les logiciels ? »\r\n« Quels sont les impacts si les versions changent ? »\r\n« Et la cybersécurité, tu y as pensé ? »\r\n\r\nLes plus techniques ajoutent :\r\n« dns-nameservers n’est pas dans le fichier interfaces. »\r\n« apache2, en prod, sans durcissement ? Non. »\r\n\r\nChacun y va de son détail, de son ajustement, de sa remarque.\r\nEt au milieu de tout ça, Nathan reste là — il lit, répond, apprend.\r\nIl ne se vexe pas. Il continue. Parce que lui, il voulait juste partager.\r\n--\r\n\r\nActe IV – LinkedIn, ou la pédagogie à reculons\r\n\r\nCe n’est pas de la méchanceté.\r\nC’est pire : c’est l’habitude d’éteindre la flamme.\r\n\r\nLinkedIn regorge de gens brillants, compétents, expérimentés.\r\nMais trop souvent, ils oublient une chose : l’enthousiasme, ça se protège.\r\nÇa ne se corrige pas, ça s’encourage.\r\n\r\nFace à un jeune qui code un outil, on peut dire :\r\n« Génial, continue ! Et si tu veux aller plus loin, regarde Ansible, ça t’inspirera. »\r\n\r\nOu bien :\r\n« Ça existe déjà, ton code n’est pas durci, tu réinventes la roue. »\r\n\r\nLa première phrase fait grandir.\r\nLa seconde forme les cyniques de demain.\r\n--\r\n\r\nActe V – Ce que Nathan a compris (et que beaucoup ont oublié)\r\n\r\nMalgré les remarques, Nathan reste droit dans ses bottes.\r\nIl remercie, prend note, annonce une version 2.\r\nIl continue à coder, à apprendre, à rêver.\r\n\r\nEt c’est là que l’histoire devient belle :\r\nle garçon n’a pas perdu sa flamme.\r\n\r\nParce qu’il a compris ce que beaucoup oublient :\r\nle progrès ne vient pas de ceux qui savent tout, mais de ceux qui essaient.\r\n--\r\n\r\nÉpilogue – Pour ceux qui cassent les pattes sans le vouloir\r\n\r\nLa prochaine fois qu’un étudiant publie fièrement son petit outil, son script, sa maquette,\r\nsouvenez-vous : il ne cherche pas un audit de sécurité.\r\nIl cherche un peu de reconnaissance.\r\n\r\nEt peut-être que dans dix ans, ce même étudiant sera ingénieur, architecte, CTO.\r\nEt qu’il se souviendra du jour où, au lieu de lui tendre la main,\r\non lui a tendu une liste de dépendances manquantes.\r\n\r\nAlors, la prochaine fois, laissez-le être fier.\r\nCorrigez, si vous voulez — mais surtout, encouragez.\r\n\r\nParce que casser des pattes, c’est facile.\r\nFaire pousser des ailes, c’est autrement plus noble.\r\n\r\nEt puis, après tout…\r\npeut-être que Nathan préfère le Bash et APT à Ansible, npm ou autres —\r\net c’est très bien comme ça.\r\n--\r\n\r\n🧠 Morale de l’histoire\r\n\r\nSur LinkedIn, il y a ceux qui montrent ce qu’ils savent faire,\r\net ceux qui montrent qu’ils savent mieux.\r\nLes premiers construisent.\r\nLes seconds commentent.\r\n\r\n🔗 Post original de Nathan Lempereur"},"score":0.75,"snippet":"…assionné d’informatique, il publie fièrement :\r\n« Sortie de <mark>Srv</mark>Tools 1.0 !!\r\nJ’ai conçu un outil pour simplifier l’installation et la configuration de serveurs Linux. »\r\n\r\nUn projet open-source, rédigé en Bash, pensé pou…","tier":2},{"article":{"uuid":"91efb488-90c1-49ea-8664-ff6f7a3ffeea","slug":"ssh","title":"ssh","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-05-01 06:23:56","created_at":"2023-05-01 06:23:56","updated_at":"2023-05-01 06:23:56","plain":"est un programme pour se connecter à une machine distante et pour effectuer des commandes sur cette machine. La connexion et les échanges sont sécurisés. L'identité utilisé sur le poste distant peut être différente de l'identité du poste local utilisé. La connexion  nécessite d'un  sur la machine distante.\nConnexions sécurisées et simplifiées grâce à l'authentification par clé publique et privée : principe\nPour simplifier et sécuriser la connexion à une machine distante, il est possible d'utiliser une méthode basée sur l'authentification par clé publique et privée. Cette approche élimine la nécessité de saisir un login et un mot de passe à chaque connexion. Au lieu de cela, la connexion SSH vérifiera votre clé privée avec la clé publique enregistrée sur le serveur distant. Cette méthode présente plusieurs avantages. Elle élimine la complexité liée à la gestion des mots de passe et permet un gain de temps considérable au quotidien. De plus, elle offre un niveau de sécurité supérieur, car les clés utilisées sont beaucoup plus robustes que les mots de passe traditionnels. Si plusieurs utilisateurs doivent accéder au serveur distant, SSH permet de gérer plusieurs paires de clés, permettant ainsi à chaque utilisateur de se connecter avec sa propre clé. Si vous avez la responsabilité de plusieurs serveurs, vous pouvez utiliser la même clé publique sur tous les serveurs. Voici un guide détaillé pour vous aider à créer un jeu de clés sur votre poste de travail. Nous allons générer deux clés : une clé privée et une clé publique. Seule la clé publique devra être déployée sur les différents serveurs, tandis que la clé privée doit être conservée précieusement sur votre ordinateur.\nCréation d'un jeu de clés ecdsa pour une connexion SSH sécurisée\nL'algorithme de signature numérique ecdsa est un nouveau standard utilisant les courbes elliptiques, réputé pour sa sécurité et sa performance. La taille maximale des clés supportées est de 521 bits, et la plupart des clients SSH le prennent en charge. Si vous préférez utiliser l'algorithme RSA, vous pouvez simplement remplacer \"ecdsa\" par \"rsa\" dans les étapes suivantes. Étape 1: Génération de la clé SSH Pour créer une clé SSH de type \"ecdsa\", vous pouvez utiliser la commande suivante avec ssh-keygen. L'option -t spécifie le type de clé, et l'option -b définit la longueur de la clé.\n- Spécification de l'emplacement du stockage de la clé (optionnel) Si vous souhaitez spécifier un emplacement particulier pour stocker la clé, vous pouvez utiliser l'option -f suivi du chemin d'accès souhaité. Par exemple :\n- Ajout d'un commentaire à la clé (optionnel) Si vous souhaitez ajouter un commentaire à la clé pour une meilleure identification, vous pouvez utiliser l'option -C suivi du commentaire souhaité. Par exemple : Étape 2: Sécurisation de la clé privée Il est crucial de sécuriser la clé privée et de limiter l'accès aux personnes autorisées à l'utiliser. Lors de la création de la clé, le programme ssh-keygen vous demandera de définir une passphrase (mot de passe) pour la clé privée. Assurez-vous d'utiliser une passphrase sécurisée et de la mémoriser. Les caractères que vous entrez n'apparaîtront pas à l'écran pour des raisons de sécurité. En suivant ces étapes, vous aurez créé un jeu de clés ecdsa pour une connexion SSH sécurisée. Veillez à bien protéger la clé privée et à utiliser une passphrase forte pour garantir la sécurité de votre connexion.\nContrôle et gestion des clés dans SSH Pour contrôler vos clés SSH et effectuer des opérations de gestion, vous pouvez suivre les étapes suivantes : Étape 1: Lister les clés présentes dans votre compte Utilisez la commande suivante dans votre terminal pour lister les clés présentes dans votre répertoire /.ssh/ : Cette commande affichera la liste des clés présentes, le cas échéant. Étape 2: Afficher le contenu d'une clé (à utiliser avec précaution) Si vous souhaitez afficher le contenu d'une clé spécifique, vous pouvez utiliser la commande suivante : Remplacez \"maCle\" par le nom de votre clé. Cependant, il est important de noter que l'affichage du contenu d'une clé publique ou privée à l'aide de la commande \"cat\" est une pratique peu recommandée en raison de la sensibilité des informations contenues dans la clé. Veillez à utiliser cette commande avec précaution et évitez de divulguer le contenu de vos clés. Il est essentiel de prendre des mesures pour sécuriser vos clés SSH, telles que la protection de la clé privée avec une passphrase et le contrôle strict des autorisations d'accès aux fichiers de clés. En suivant ces étapes, vous pouvez contrôler et gérer vos clés SSH de manière sécurisée. Veillez à respecter les bonnes pratiques en matière de gestion des clés et à prendre les mesures appropriées pour protéger vos informations sensibles.\nCopier et utiliser une clé publique avec SSH\nGuide étape par étape pour copier et utiliser une clé publique avec SSH sous Linx.\n- Pour utiliser la clé, vous devez procéder à la copie de votre clé publique vers le poste distant. La clé publique est généralement stockée dans un fichier nommé \"idrsa.pub\" situé dans le répertoire \".ssh\" de votre dossier utilisateur. L'étape suivante consiste à ajouter cette clé publique au fichier \"authorizedkeys\" du dossier \".ssh\" sur l'ordinateur distant. Voici un exemple plus détaillé du processus : 1. Tout d'abord, identifiez l'emplacement de votre clé publique. Par défaut, elle se trouve dans le fichier \"/.ssh/idrsa.pub\". 2. Ensuite, ouvrez une session sur le serveur distant en utilisant la commande SSH : Remplacez \"utilisateur\" par votre nom d'utilisateur et \"srvprod.aceinternet.fr\" par l'adresse du serveur distant. 3. Une fois connecté au serveur distant, créez le dossier \".ssh\" dans votre répertoire utilisateur s'il n'existe pas déjà : 4. Utilisez la commande \"ssh-copy-id\" pour copier votre clé publique sur le serveur distant et l'ajouter au fichier \"authorizedkeys\" : Cette commande copie le contenu de votre clé publique dans le fichier \"authorizedkeys\" sur le serveur distant, ce qui vous permettra de vous connecter sans avoir à saisir de mot de passe. Cette commande est a utiliser sur votre poste local. 5. Après avoir exécuté la commande, vous serez invité à saisir votre mot de passe pour le serveur distant une dernière fois. Entrez-le et la copie de votre clé publique sera effectuée. Une fois que vous avez suivi ces étapes, vous devriez être en mesure de vous connecter au serveur distant en utilisant votre clé privée, sans avoir à saisir votre mot de passe à chaque fois. Veuillez noter que les noms de fichiers et les chemins d'accès peuvent varier en fonction de votre configuration spécifique, mais les étapes générales restent les mêmes.\nGestion des clés SSH avec un fichier de configuration\nPour faciliter la gestion des connexions SSH, vous pouvez créer un fichier de configuration qui regroupe toutes les informations nécessaires. Voici un exemple de configuration : Ce fichier de configuration permet de spécifier les paramètres de connexion pour l'hôte distant \"srvprod.aceinternet.fr\". Les lignes suivantes indiquent respectivement le nom d'hôte, le port, le nom d'utilisateur et le chemin vers la clé privée à utiliser pour cette connexion. Il est important de protéger le fichier de configuration pour garantir la sécurité de vos informations sensibles. Vous pouvez définir les permissions appropriées en utilisant les commandes suivantes : La première commande  définit les permissions du fichier de configuration de manière à ce qu'il soit accessible en lecture et écriture uniquement par le propriétaire (vous), et aucun accès en lecture pour les autres utilisateurs. La deuxième commande  garantit que le fichier appartient à l'utilisateur courant. En veillant à protéger votre fichier de configuration, vous pouvez centraliser et gérer plus facilement vos connexions SSH en utilisant les paramètres spécifiés dans ce fichier. Cela simplifie également la maintenance et la modification des connexions SSH.\nConseils en cas de panne\nQue faire en cas de changement de la clé publique de l'hôte distant\nUne clé publique de l'hôte distant est un élément essentiel dans le système d'authentification et de sécurité utilisé par le protocole SSH (Secure Shell) lors des connexions à distance. Lorsque vous vous connectez à un hôte distant via SSH, l'hôte présente sa clé publique au client pour vérifier son identité. La clé publique de l'hôte distant est générée lors de la première connexion SSH à cet hôte et est ensuite stockée dans le fichier knownhosts du client. Elle est associée à une signature numérique unique qui permet d'authentifier l'hôte distant de manière sécurisée. Cette clé publique est utilisée pour chiffrer les données envoyées au serveur, assurant ainsi la confidentialité des communications. Lorsque vous vous reconnectez à l'hôte distant ultérieurement, le client SSH vérifie si la clé publique présentée par l'hôte correspond à celle enregistrée dans le fichier knownhosts. Si les clés correspondent, la connexion est établie en toute sécurité. Cependant, si la clé publique a changé depuis la dernière connexion, le client SSH émet un avertissement indiquant qu'une attaque potentielle de type \"man-in-the-middle\" est possible, et la connexion est bloquée par mesure de sécurité. La clé publique de l'hôte distant joue donc un rôle crucial dans l'établissement de connexions sécurisées via SSH. Elle permet d'authentifier l'hôte distant et de détecter tout changement potentiel dans l'identité de l'hôte. La gestion appropriée des clés publiques et la vérification de leur validité contribuent à assurer la sécurité des connexions SSH.\n- Si vous rencontrez une erreur indiquant que la clé publique de l'hôte distant a changé lors d'une tentative de connexion SSH, voici les étapes à suivre pour résoudre ce problème : 1. Tout d'abord, lorsque vous essayez de vous connecter à l'hôte distant avec la commande , vous obtenez un message d'erreur indiquant que la clé a changé et qu'une attaque de type \"man-in-the-middle\" est possible. 2. Cela signifie que la clé ECDSA (ECDSA key) utilisée pour sécuriser la connexion entre votre client et l'hôte distant a été modifiée depuis votre dernière connexion. Cette clé est stockée localement sur votre client, dans le fichier knownhosts, qui se trouve généralement dans le répertoire caché .ssh de votre utilisateur (par exemple, /home/cedric/.ssh/knownhosts). 3. Pour résoudre ce problème, vous devez réinitialiser l'entrée de l'hôte distant dans le fichier knownhosts. Vous pouvez le faire en utilisant la commande suivante : Cette commande supprimera l'enregistrement de l'hôte 192.168.100.5 du fichier knownhosts. 4. Une fois que vous avez réinitialisé l'entrée, vous pouvez vous connecter à nouveau à l'hôte distant en utilisant la commande . Cette fois-ci, la nouvelle clé publique sera enregistrée dans le fichier knownhosts, et vous devriez pouvoir vous connecter sans erreur. En suivant ces étapes, vous pourrez résoudre le problème lié au changement de la clé publique de l'hôte distant et vous reconnecter en toute sécurité.\nPossible usurpation DNS\nLorsque vous essayez de vous connecter à un hôte distant via SSH, vous pouvez rencontrer un avertissement indiquant une possible usurpation DNS. Voici le message d'erreur associé : Ce message indique que la clé de l'hôte distant \"raspberrypi\" a changé, mais l'adresse IP correspondante (192.168.100.84) est restée inchangée. Cela peut signifier deux choses : soit une usurpation DNS est en cours, soit l'adresse IP de l'hôte et sa clé de connexion ont changé simultanément. Pour résoudre ce problème, vous devez supprimer l'enregistrement associé à l'hôte en question. Vous pouvez le faire en utilisant la commande suivante : Cette commande supprimera l'enregistrement de l'hôte \"raspberrypi\" du fichier knownhosts. Une fois que vous avez supprimé l'enregistrement, vous pouvez essayer de vous reconnecter à l'hôte. Cette fois-ci, l'association entre le nom de l'hôte et sa clé sera enregistrée à nouveau dans le fichier knownhosts. Assurez-vous de suivre ces étapes pour garantir la sécurité de votre connexion SSH et éviter les risques potentiels liés à une usurpation DNS.\nChoix entre RSA et ECDSA\nLe choix entre l'utilisation d'ECDSA (Elliptic Curve Digital Signature Algorithm) ou de RSA (Rivest-Shamir-Adleman) dépend de plusieurs facteurs, notamment les considérations de sécurité et les préférences personnelles. ECDSA utilise des courbes elliptiques pour la génération de clés et les opérations de signature numérique. Il est généralement considéré comme plus efficace en termes de performances et d'utilisation de la bande passante. Les clés ECDSA sont également plus courtes que les clés RSA équivalentes, ce qui peut être avantageux dans certains cas. D'autre part, RSA est un algorithme de cryptographie asymétrique plus ancien et largement utilisé. Il est éprouvé et bien pris en charge par de nombreuses infrastructures et logiciels. RSA est généralement considéré comme étant plus sûr pour des longueurs de clé équivalentes, mais nécessite des clés plus longues pour offrir un niveau de sécurité comparable à ECDSA. En fin de compte, le choix entre ECDSA et RSA dépend de la compatibilité avec les systèmes existants, des performances souhaitées et des recommandations de sécurité spécifiques. Il est recommandé de se référer aux recommandations de sécurité en vigueur et de prendre en compte les spécifications et les exigences propres à votre environnement avant de faire un choix.\nScript Bash pour générer une clé privée SSH et configurer la connexion\nVoici un script Bash qui demande à l'utilisateur de saisir le nom de l'hôte distant, le numéro de port et son nom d'utilisateur pour se connecter via SSH. Il génère ensuite une clé privée et la pousse sur l'hôte distant. Enfin, il écrit un fichier de configuration dans le répertoire \".ssh/config\". Le nom de la clé privée générée sera basé sur le nom de l'hôte distant fourni par l'utilisateur, ce qui permet de générer des clés privées uniques pour chaque hôte distant. Par exemple, si l'utilisateur saisit \"srvprod.aceinternet.fr\" comme nom d'hôte distant, la clé privée sera enregistrée sous . Assurez-vous d'exécuter le script en tant qu'utilisateur disposant des droits nécessaires pour effectuer les opérations (par exemple, l'utilisateur courant doit pouvoir générer une clé privée, écrire dans le répertoire  et copier la clé publique sur l'hôte distant)."},"score":0.75,"snippet":"…H : Remplacez &quot;utilisateur&quot; par votre nom d&#039;utilisateur et &quot;<mark>srv</mark>prod.aceinternet.fr&quot; par l&#039;adresse du serveur distant. 3. Une fois connecté au serveur distant, créez le dossier &quot;.ssh&quot; dans votre répertoire utilisateur s&#039;i…","tier":2},{"article":{"uuid":"3c9af6ba-9ba2-4263-8c61-ec1d5c273947","slug":"monter-son-nas","title":"NAS - espace de stockage réseau","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-10 22:48:30","created_at":"2023-02-10 22:48:30","updated_at":"2023-02-10 22:48:30","plain":"Voici quelques informations et idées pour monter un serveur NAS. Solution Raspberry Pi 4\nBoitier à 4 disques. Il est possible de connecter à n'importe quel ordinateur avec son port USB 3. C'est une connexion logicielles de JBODY. C'est à dire que chaque disque est vue de manière entière. Il n'y a pas de montage RAID ou de subterfuge qui modifierait les partitions des disques. Raspberry Pi 4 Solution x86 mini-ATX\nSolution qui permet de connecter 12 disques dur en SATA. Nombre de connecteurs SATA II: 4\\\\\nNombre de connecteurs SATA III: 8 Cette solution coute 755€. Voici le détail.\nJe ne l'ai pas mise en œuvre car elle est trop chère.\nCarte mère\nC2550D4I - ASROCK MAINBOARD MINI-ITX WITH INTEL AVOTON C2550 4-CORE CPU 12x SATA PORTS Amazon\\\\\nhttp:www.amazon.fr/C2550D4I-ASROCK-MAINBOARD-MINI-ITX-AVOTON/dp/B00GG94YDS/ref=sr16?ie=UTF8&qid=1448147086&sr=8-6\\\\\n306 EUR LDLC\\\\\nhttp:www.ldlc.com/fiche/PB00161902.html\\\\\n290 EUR Boitier\nSilverstone SST-DS380B Noir Amazon\\\\\nhttp:www.amazon.fr/Silverstone-71062-SST-DS380B-Noir/dp/B00HVKMI9S/ref=pdsim1472?ie=UTF8&dpID=41F2sZSzMvL&dpSrc=sims&preST=ACUL160SR157%2C160&refRID=0ANP2KDSHB27SS6A8NPT\\\\\n165 EUR LDLC\nhttp:www.ldlc.com/fiche/PB00165252.html\\\\\n199 EUR Mémoire\nCrucial DDR3 8 Go 1600 MHz ECC CL11\n à doubler  LDLC\\\\\nhttp:www.ldlc.com/fiche/PB00170546.html\\\\\n2 x 90 EUR Alimentation\nSilverStone SFX ST45SF-G v2.0 LDLC\\\\\nhttp:www.ldlc.com/fiche/PB00157913.html\\\\\n120 EUR Amazon\\\\\nhttp://www.amazon.fr/SilverStone-SFX-ST45SF-G-v2-0-Alimentation/dp/B008VQ2Y4K/ref=sr12?ie=UTF8&qid=1448148144&sr=8-2\\\\\n165 EUR**"},"score":0.75,"snippet":"Voici quelques informations et idées pour monter un serveur NAS. Solution Raspberry Pi 4\nBoitier à 4 disques. Il est possible de connecter à n&#039;importe quel ordinateur avec son port USB 3. C&#039;est une connexion logicielles …","tier":2},{"article":{"uuid":"4cefdfe0-4a7e-40c8-bebf-3103f4d222d9","slug":"http-apache2","title":"Configurer un site en http pour un sous-domaine spécifique","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 16:12:18","created_at":"2023-02-09 16:12:18","updated_at":"2023-02-09 16:12:18","plain":"Voici mes prises de notes pour configurer un site Internet http. Le configuration est destinée pour un site Internet dont le sous-domaine est srv195. Pré requis\nLa configuration du site Internet s'effectue dans un fichier de configuration.\nIl accepte une connexion sur le port http 80.\nIl accepte les connexions vers le .\nIl permet d'avoir des logs dans des dossiers séparés Configuration Apache 2\nOn configure un site web à partir d'un fichier  qui contient des directives. Dans notre exemple de fichier , il sera configuré le site Internet . Le fichier à créer est  : Activer la configuration du site\nOn active la configuration du site en utilisant le binaire  Et si tout se passe bien, on recharge la configuration d'Apache 2 sans avoir besoin de redémarre le service :"},"score":0.75,"snippet":"…est destinée pour un site Internet dont le sous-domaine est <mark>srv</mark>195. Pré requis\nLa configuration du site Internet s&#039;effectue dans un fichier de configuration.\nIl accepte une connexion sur le port http 80.\nIl accepte les c…","tier":2}]