---- Gabriel Detraz a écrit ----

> Salut à tous,
>
>
> Pour ceux qui n’étaient pas là, voici ce qui s’est dit (de mémoire, les présents corrigeront) vendredi.
>
>
> Présents : Chirac, Charlie, Grizzly et Esum
>
>
> A noter que la réunion n’a pas durée très longtemps à cause du départ de Charlie :
>
>
> Point sur ce qui a été fait niveau infra : - mise en place de re2o-server, vm avec un serveur web apache de dev et bdd sur thot (postgresl)
>
> - mise en place de re2o-ldap, contenant le ldap de re2o
>
> - mise en place de re2o-services, contenant les services dhcp, dns notamment.
>
> - import de la bdd actuel avec un script d’import bien avancé, permettant de faire des tests ( presque tout passe, sauf les serveurs disposant de la même mac sur plusieurs VLAN : https://gitlab.crans.org/nounous/scripts/blob/master/re2o/import_crans.py )
>
>
> Ces vm sont sur adh/adm.
>
>
> Charlie suggère de rajouter l’embryon de parefeu sur services, de créer des vlans dédiés en dehors de adm avec des id élevés ( > 30 ? ); enfin de tester sur ces vlan un mini réseau, avec également la vm re2o-services qui servirait de routeur. Tout le monde semble d’accord là dessus.

Hmm de mémoire 5-1 m'avait dit que son "embryon" était operationel. A confirmer ceci-dit

>
>
> Ce qui a été fait niveau dev : - factorisation du système de gestion des acl
>
> - portages de scripts divers mais essentiels ( chsh, chgpass, unifi-ap-sync, dernière connexion) via des commandes django et des appels aux forms et aux validations des models

Quel en est l'utilité ? c'est une commande qu'on lance depuis django manage.py ? On peut l'appeler depuis l'extérieur ?

>
> - enregistrement de l’emplacement des switchs et génération de la map de la topologie du réseau
>
> - affichage pretty des switchs (equivalent de swicths2 pretty)

Fort pretty en effet
>
> - fonction de ménage cableur
>
> - possibilité d’éditer la liste des shells sans passer par le /admin
>
> - model borne wifi spécifique
>
>
> Ces taches ont une criticité diverse. Sur le reste, il faut avancer dans le code, on fait grosso modo la liste des chantiers. En critique/prioritaire, il y a : - firewall, à partir de l’embyron présent dans re2o (nftable ? )


Cf comment au dessus

>
> - generation de la conf des switchs, code modulaire permettant de générer de la conf pour d’autre modèles que des hp. Voir une solution existante ? - adherent : gestion de la creation des homes, à inclure dans re2o-tools
>

C'est-à-dire la creattion des homes ? Vous pouvez pas le faire comme c'est fait en ssh actuellement ?

>
> Enfin, on a débattu un peu sur la sécurité. Dans re2o, il n’y a qu’un seul login/mdp pour tout.
>
> Avantages :
>
> - plus simple pour les users à comprendre et à retenir comme système
>
> - permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de son compte crans en entier à un « ami »
>
> Inconvénient : - le mdp est le même partout, cela peut poser un problème de sécu en particulier pour les admin.
>
>
> On identifie les fonctions sensibles : il s’agit de l’accès web re2o, et des accès serveurs (sudo en particulier).
>
> L’autre problème concerne la phase transitoire, il va falloir gérer les mdp legacy des machines, mais il « suffira » de tweaker un peu auth.py au moins temporairement pour ça.
>
>
> Plusieurs solutions possibles :
>
>
> Avoir un second compte; on est tous d’accord pour dire que les gens ne s’y tiendront pas, cette solution semble trop pénible.
>
>
> Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en place un second mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas satisfaisant d’après Charlie, cela n’augmente pas la sécurité, en effet c’est toujours le même mot de passe entre l’accès serveur, l’accès gitlab ou l’accès mail, mais surtout les accès serveurs sudo qui sont la pièce critique, comme actuellement au CRANS.
>
>
> On peut forcer l’authentification par clef ssh pour les admin, comme ça si un mot de passe est compromis, les accès serveurs ne le sont pas. Problème : cela ne résout pas le problème de l’accès re2o-web qui serait toujours le même mot de passe.

Moi forcer l'auth ssh ça me gêne pour plusieures raisons mais vous avez peut être des solutions :
1) si tu veux faire un sudo..., tu le fais comment sans rentrer ton mdp ? Tu peux configurer sudo pour être basé sur ta clé ssh ? Parce que si tu dois taper ton mdp, ça pert de son intérêt.
2) si t'as ssh sur un serveur X et tu veux ssh sur un serveur Y(exemple de j'accède aux serveurs depuis l'extérieur donc en passant par un serveur), tu fais comment ? Tu laisses une clé privé dans ton home ? Je suis pas fan de laisser n'importe qui qui est sudo la possibilité de se connecter avec mon compte (même si c'est vrai tu peux chiffrer ta clé, permettre de la voir, c'est un premier pas vers l'insécurité. Et si tu chiffres, tu met un mot de passe, et en pratique ce sera le même que re2o je pense)

>
>
> On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe pour les admin permettant de récupérer leurs droits sur re2o-web, ce qui permet de couvrir à peu près tout. Le débat reste ouvert.

Sachez que vous ne pourrez pas forcer l'auth ssh partout. Je sais que chez nous, par experience, c'est mort pour que tous le monde ait une clé ssh. Et je pense aussi pour que les gens s'emmerdent avec deux mots de passe (même les admins). Ça va plus fermer les portes aux curieux qui veulent découvrir le rézo qu'etre bénéfique je pense (pour rennes en tout cas).
Donc même si je suis d'accord avec vous sur le principe, en pratique, ce serait cool de laisser la possibilité de continuer comme c'est actuellement


>
>
> Voilà à peu près ce qu’on a dit,
>
>
> Cordialement,
>
>
> — Chirac