Le 12409i�me jour apr�s Epoch, [EMAIL PROTECTED] �crivait: > Bonjour, > > Pouvez-vous m'ouvrir l'esprit? ;o)
Je n'ai pas cette pr�tention, alors si quelqu'un pouvait me relire et me corriger, je serais ravi. > En r�gle g�n�ral, le login sous root est d�conseill� > en dehors d'une console locale sous surveillance. Oui, �a �vite d'avoir des droits sur une machine depuis un endroit diff�rent d'o� est le clavier. > M�me pour SSH, j'ai lu qu'il �tait conseill� de > d�sactiver la connexion sous root et d'utiliser 'sudo' > pour autoriser certaines actions � un utilisateur > accr�dit�. Pas forc�ment. Tu peux aussi interdire l'acc�s par mot de passe et forcer l'�change de clefs. Dans l'absolu c'est la r�gle de ma premi�re r�ponse qui s'applique. Mais si tu autorises l'acc�s � un user avec le droit de faire des 'sudo', alors le vilain craker essayera de faire pareil. > Si je dois administrer une machine � distance avec > SSH, quelle am�lioration de la s�curit� puis-je > esp�rer avec ce principe? > > Un quidam peut arriver � truander le syst�me, faire > usage de mon userid et b�n�ficier des droits que j'ai > gr�ce � 'sudo'. Clair. Dans cette situation, le principe d'obligation de clefs SSH est � mon avis un bon niveau de s�curit�. A condition �videmment que la machine � partir de laquelle tu fais �a soit prot�g�e. Tu peux aussi pousser le vice (la parano) jusqu'� stocker la clef SSH sur une clef USB. > De m�me, '/etc' n'est pas prot�g� en lecture et les > fichiers de configurations sont lisibles. Il aura donc > un catalogue des droits qui me sont attribu� par > 'sudo'? Oui, mais si ces droits sont assez restrictifs, il ne pourra rien faire. La s�curit� par l'obscurantisme n'est pas une bonne s�curit�. -- The good oxymoron, to define it by a self-illustration, must be a planned inadvertency. -Wilson Follett
