Pour la plupart, il y a peu d'avantages à désactiver les connexions root distantes. Il aide marginalement à appliquer une politique qui permet aux administrateurs de se connecter via leurs propres comptes et sude rooter si nécessaire (ou à utiliser sudoéventuellement avec sudosh... selon vos politiques).
La création de mots de passe root extrêmement longs et encombrants (efficaces tant que vous n'utilisez pas encore l'ancien hachage de sel DES + 12 bits pour vos mots de passe) est à peu près aussi efficace pour appliquer une telle politique.
Un site avec lequel je suis familier avait un système par lequel les mots de passe uniques étaient générés de manière aléatoire pour chaque hôte, stockés dans une base de données et envoyés aux systèmes. Les administrateurs devaient utiliser sshavec leurs comptes normaux et sudopour la plupart des opérations. Cependant, le mot de passe root leur était accessible via un service Web interne basé sur SSL (qui nécessitait en outre leur jeton RSA SecurID et leur PIN). La récupération d'un mot de passe root impliquait la saisie d'une justification (généralement un lien vers un numéro de ticket Remedy (TM)) et des accès où audités périodiquement. L'une des rares raisons acceptables d'utiliser directement le mot de passe root était dans les cas où un système a été arrêté fsckpendant le processus de démarrage ... etsuloginnécessitait un vrai mot de passe root pour exécuter manuellement les processus de vérification et de réparation du système de fichiers. (Il y a eu une discussion sur les méthodes alternatives pour cela --- qui sont relativement faciles pour Linux, mais deviennent beaucoup plus difficiles lorsque vous essayez d'étendre vos procédures pour tenir compte des nombreux systèmes HP-UX, AIX et SunOS et Solaris plus anciens qui étaient encore en production dans cet environnement).
Il y a des cas où un mot de passe root est nécessaire - ou du moins est la meilleure alternative disponible. Le garder disponible tout en le rendant suffisamment résistant aux types de menaces que vous pouvez anticiper est généralement votre meilleure stratégie.
Un autre site que je connais a une approche plutôt élégante de la gestion décentralisée des comptes. Ils ont des packages user- * et sudo- * (pensez RPM) qui sont installés dans les systèmes en utilisant les procédures normales de gestion des packages et l'infrastructure d'automatisation. Dans leur cas, le package sudo- * dépend du package user- * correspondant. C'est bien car cela vous permet d'avoir des clusters de machines avec des comptes localisés (tous les comptes sont des administrateurs, des développeurs, du personnel de support ou des comptes "sans tête") et élimine la dépendance à LDAP / NIS ou à d'autres services d'identité et d'authentification en réseau. (Cela réduit le couplage entre les systèmes les rend beaucoup plus robustes).
On pense que cette approche me plaît, c'est qu'elle donne de la souplesse. Toute personne disposant d'un sudoaccès peut émettre une commande pour ajouter un utilisateur normal ou un autre sudocompte d'utilisateur. Donc, si je travaille sur un ticket, toutes les personnes qui ont déjà accès à un système peuvent facilement me donner accès. Il n'y a pas de retards pendant qu'un ticket pour m'ajouter à une liste de contrôle d'accès dans une base de données centrale passe par un processus d'approbation centralisé et propage finalement un changement vers le système en question. N'importe lequel des utilisateurs autorisés sudosur le système peut me donner accès et me retirer ultérieurement. (Oui si j'étais méchant et qu'ils me jouentsudoJe pourrais malicieusement modifier les choses pour conserver l'accès ... en fait, je pourrais faire certaines choses en tant qu'utilisateur normal pour conserver l'accès après une telle suppression. Cependant, ce n'est pas la menace qui les inquiète. Mon accès est toujours limité à un nombre relativement plus faible de systèmes dans l'ensemble; donc l'impact d'un compte compromis est encore plus limité que la plupart des schémas similaires que j'ai vus.