Une utilisation du ~/.ssh/authorized_key local est adaptée à un petit parc de machine.
Dès l'instant ou on doit gérer beaucoup de machines avec des updates régulières de ce fichier, alors il faut commencer à penser à utiliser d'autres solutions, plus adaptées.
Pas entièrement d'accord... gérer manuellement un authorized_keys local n'est pas adapté à un parc qui grossit ou qui évolue, mais rien n'empêche de le gérer avec ansible/rex (qui sont agentless) dans des parcs plus importants, à priori.
Bon, ce n'est pas le plus efficace, certes, mais l'intérêt d'ansible/rex, c'est que, justement, pas besoin d'installer quoique ce soit sur la cible, ce qui du coup me fais un peu tiquer sur le "problème" de l'OP.
Bon, dans le cas d'ansible, il faut python, qui est installé presque partout, mais quand même moins souvent que perl, qui est nécessaire pour rex: c'est la raison pour laquelle j'ai opté pour rex au taf, sur des systèmes pour lesquels il me faut minimiser le nombre de dépendances (et qui n'ont aucune raison actuelle d'utiliser python).
Je serais bien partit sur cfengine3 (qui me ferait sauter pas mal de libs perls), mais c'est franchement compliqué de savoir comment le configurer, quels daemons servent vraiment à quoi et on besoin de quels autres... et avec le manque de temps, suis parti sur un agentless en me disant que je pourrais automatiquement passer à plus robuste et automatique le jour ou j'aurai mis en place tout le nécessaire... d'ici 2-3 siècles, avec du bol :D
[^] # Re: LDAP ?
Posté par freem . En réponse au journal Gestion de clés ssh publiques (~/.ssh/authorized_keys). Évalué à 4.
Pas entièrement d'accord... gérer manuellement un authorized_keys local n'est pas adapté à un parc qui grossit ou qui évolue, mais rien n'empêche de le gérer avec ansible/rex (qui sont agentless) dans des parcs plus importants, à priori.
Bon, ce n'est pas le plus efficace, certes, mais l'intérêt d'ansible/rex, c'est que, justement, pas besoin d'installer quoique ce soit sur la cible, ce qui du coup me fais un peu tiquer sur le "problème" de l'OP.
Bon, dans le cas d'ansible, il faut python, qui est installé presque partout, mais quand même moins souvent que perl, qui est nécessaire pour rex: c'est la raison pour laquelle j'ai opté pour rex au taf, sur des systèmes pour lesquels il me faut minimiser le nombre de dépendances (et qui n'ont aucune raison actuelle d'utiliser python).
Je serais bien partit sur cfengine3 (qui me ferait sauter pas mal de libs perls), mais c'est franchement compliqué de savoir comment le configurer, quels daemons servent vraiment à quoi et on besoin de quels autres... et avec le manque de temps, suis parti sur un agentless en me disant que je pourrais automatiquement passer à plus robuste et automatique le jour ou j'aurai mis en place tout le nécessaire... d'ici 2-3 siècles, avec du bol :D