Re: ssh : Permission denied (publickey,keyboard-interactive).
Le mer 17/07/2002 à 12:57, georges mariano a écrit :
>
> > PubkeyAuthentication yes
>
> apparemment ça suffit
>
> (comprends pas d'où vient ce réglage, ça marchait depuis des mois)
>
> merci... (pourtant j'avis un peu scruté ... ;-)
>
> avant le coup de gueule, un grand merci à ceux qui m'ont répondu en
> m'évitant ainsi de perdre encore plus de temps à réparer ce que
> l'upgrade avait détruit (<-- j'insiste, le service que _je_ avais
> défini a été cassé).
>
> <coup-de-gueule-debut>
> je sais pas trop pourquoi, mais en ce moment je commence en avoir
> marre de me coltiner la logique des mainteneurs de paquets (qui des
> users inutiles, qui ce genre de surprise à l'upgrade, qui des trucs
> assez rigolos dans la recompilation de paquets, ...)
>
> faudrait peut-etre qu'on revienne aux fondamentaux :
> dans le cas d'un upgrade (i.e le service déjà opérationnel)
>
> Préserver le service ça veut dire __respecter l'install en place__,
> quelle qu'elle soit.
>
> Si l'install est mauvaise, on prévient clairement l'admin, on le
> harcèle s'il faut, mais on ne touche rien. S'il fait le sourd et qu'il
> a ensuite un problème, il est __responsable__.("on t'avait
> prévenu...")
>
> La mainteneur n'est pas responsable des fautes de l'admin local, il
> n'a pas a vouloir faire le travail à sa place.<coup-de-geule-fin>
>
> vous en faites pas, ça va me passer ... ;-)
Hummm...
Que de mauvaise foi là-dedans !
Pour ma part, j'estimes que l'admin qui fait sa mise à jour est tout
autant responsable des dommages collatéraux. Il est trop facile de
rejetter la faute au responsable du paquet.
Si ton service est capital, tu te dois de faire tes propres tests sur
des machines de tests et non directement sur des machines de production
et c'est le B.A.-BA de l'admin, je suis désolé...
ALors, aprés si tu ne prends pas le soin de vérifier que ça fonctionne à
nouveau et que tu pars parce que c'est l'heure, tu en es responsable !
Personnellement, j'ai un serveur ssh qui n'accepte que l'identification
par clé publique et je n'ai jamais eu de problèmes de ce genre avec mes
mises à jour justement parce que je prends toujours des précautions
élémentaires. Et,j'ajouterai qu'il en va de même pour un autre service
nommé vtun, dont le paquet a eu un souci au moment de la mise à jour et
dont le démon ne repartait pas. Crois-tu que j'avais fait de suite la
mise à jour sur mon serveur ? Hé bien non !...
Du coup, j'ai attendu que le problème se tasse avant de le faire sur le
serveur, point final.
Utiliser une Debian même stable ne dispense pas des règles élémentaires
d'administration de services.
Amicalement !
--
Raphaël SurcouF
surcouf@nocternity.net
#debianfr @ Undernet.org
--
To UNSUBSCRIBE, email to debian-user-french-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: