Reprise du message précédent :
http://www.videocoach.com/conseil/ [...] iversaire/

putain, mais je suis un peu désespéré, l'impression qu'il n'y a pas de "bonne" manière de gérer ce pb, même les pratiques standards du secteur elles me conviennent pas
 
sans compter que je suis en train de foutre le bordel dans les droits pour pouvoir déployer mon truc sans sudo (user dans le groupe www-data et g+w sur le webroot, puis ensuite donner g+w au répertoires cache et upload).

 
ubuntu
 

 
One Time Password In Everything
 

 
Tu utilises sudo si tu le fais à la main. Sinon tu laisses le provisionning le faire.
 

 
J'ai bien compris que tu avais pas de problème technique, j'ai exposé le pour et le contre de chaque solution stout    
 
Pour moi le meilleur compromis vu ton environnement c'est : de mettre une auth par clé uniquement, un password FORT sur les comptes admins, de passer ces comptes admin dans le groupe "sudo" (et pas "admin", %sudo désigne le groupe sudo) et ensuite au choix : soit tu allonges le timer pour tes actions sudo, soit tu poses un NOPASSWD.
 
Pour ce qui est de remonter une plateforme rapidement : provisionning automatisé. Un coup de FAI/preseed + Puppet/Chef et ta box est up & running en 15 minutes. C'est un investissement en temps mais pour une reprise sur incident, c'est imbattable (et même dans le cas où tu bousilles une machine, effacer & réinstaller va plus vite que de diagnostiquer. Quand tu as X serveurs www derrière le LB tu te poses pas de questions.
 
Ici les clés SSH sont gérées par le provisionning de config (puppet), de même que 80% des parties système. J'ai tellement gagné de temps que je m'ennuie

 
C'est pas si dégueu que ça comme solution, j'utilise la même chose. Sans ACL ou RBAC étendues tu n'y coupes pas.

 
Oui. Ca empèche les démangeaisons et réduit les gonflements (/allergique aux piqures de moustiques).

Oui, c'est ça, on va embaucher un presta pour 3 pauvres machines

faut bien faire vivre les sysadmins

non, mais j'ai peur de faire une connerie quand même.  
 
par exemple dans mon cas ça veut dire que la racine du webroot est en write par apache (alors que c'est pas nécessaire).

et les RBAC coté passager, c'est en option ?

 
en même temps www-data est déjà owner non ? donc ajouter le groupe n'a pas de réelle incidence.

 
 
à ma gauche : root par clef
à ma droite : pas de root par clef mais un user par clef peut sudoer
 
J'attends l'explication montrant que le premier est à chier et le second bien plus sûr

 
Une faille dans l'auth SSH et c'est torché (au hasard le problème récent des clés debian)

 
les probas d'une faille dans l'auth ssh sont complètement négligeables comparés aux probas d'une faille dans sudo/d'une fuite de passwd
le point faible c'est sudo/passwd, pas ssh

Et l'utilisateur qui se connecte par clef et qui sudo sans passwd n'est pas touché par le problème ? lol ?

Pourquoi ?
Même avec un tocken ?
Même avec une clé privée protégée par une longue passphrase ?

 
Ouais, mais j'ai eu des clés corrompues et je ne me suis jamais fait taxer mon password   A ce moment là tu peux aussi interdire les users, des fois qu'ils utilisent un exploir local    
 

 
j'ai précisé que le NOPASSWD c'était pas bien  

en quoi il y aurait plus de risque de faille avec clé qu'avec password ?  

Autant de risque, c'est pour ça qu'il préconise pas le root login.
Mais il préconise surtout de continuer à se faire chier avec 15 post-it sur son bureau pour stocker les passwd, c'est nettement plus safe

 
y'a plein de gens qui utilisent des clés sans pass phrase (typiquement pour des trucs automatisés), du coup si la clé permet de se connecter en root => une clé pourrie = un shell root

 
mes password sont dans ma tête et nulle part ailleurs (ce qui fait raler certains)

pour des raisons pratiques non, j'ai créé le rep à coup de sudo et j'ai pas changé son owner.

password user ou root,  si tu as un accident toutes les données sont perdues?

ben ici c'est ça, parce qu'on les utilise 100 fois par jour entre git et ssh

Tes utilisateurs ont de la chance que tu prennes jamais de vacances

ssh-agent

 
un password ça se reset, et j'ai pas dit que j'avais le seul compte admin

c'est quoi la différence avec une clef sans passphrase ?

Ben ssh-agent + clef avec passphrase c'est la bonne solution, tu peux faire tourner l'agent pour être peinard et pas retaper ton mdp le temps que tu bosses. Le reste du temps ta clef n'est pas "nue", suffit pas de débarquer sur ta machine pour être root (évidemment si l'agent tourne 24/24 ca revient presque au même, sauf en cas de reboot)

Soit ssh-agent + plein de ssh root@XXX le temps que tu fasses ton administration (si tu veux pas taper n fois ton mdp de clef)
Soit ssh root@XXX une seule fois (un seul mdp de clef à taper) et après tu utilises screen pour avoir plein de terminaux

Enfin c'est mon avis  

c'est là que les bactéries attaquent ...

et pour l'auth sur la base de données, vous faites quoi ?

Bon dites, c'est pas Blabla@OSA ici Dehors les romanos

 
Tu crois que l'inflammation vient d'où à ton avis ?

Taiche président.

C'est à tous nous faire un présent

de bons passwords bien longs

c'est relou.
 
et vous les sotckez où pour le re-déploiement ?

Pour ça je serais près à donner mon premier enfant

(j'ai pas suivi la conversation) bof, firewall si elle est pas sur la meme machine, et baste.
(dans le cas de mysql eventuellement restreindre l'ip au niveau de l'user aussi)

 
Oui, j'ai pas trop cherché de solutions à ce niveai
 
  c'est un peu le bronx à ce niveau là, grosso modo ils sont dans le SVN de l'appli concernée

+1, c'est relou là
 
Et pis merde, un vieux password de 8 lettres+chiffres (avec un dièse au début, pour la sécurité ), en post-it sous l'écran, pour le compte root évidemment, et tu te fais pas chier avec ce bordel de sudo-machin et de chierie SSH et je ne sais quoi

C'est quoi le nouveau site genre deezer/jiwa/spotify qui est bien ?
J'ai oublié je le retrouve pas..