Na maioria das vezes, pouco é obtido desabilitando os logins raiz remotos. Isso ajuda marginalmente a impor uma política que administra o login através de suas próprias contas e su a root conforme necessário (ou usa sudo possivelmente com sudosh ... dependendo de suas políticas).
Criar senhas de raiz extremamente longas e complicadas (com efeito, desde que você ainda não esteja usando o antigo hashing de sal de DES de 12 bits para suas senhas) é quase tão eficaz para impor tal política.
Um site com o qual estou familiarizado tinha um sistema no qual as senhas exclusivas eram geradas aleatoriamente para cada host, armazenadas em um banco de dados e enviadas para os sistemas. Os administradores precisavam usar ssh com suas contas normais e sudo para a maioria das operações. No entanto, a senha raiz era acessível a eles por meio de um serviço da Web interno baseado em SSL (que exigia ainda mais seu token RSA SecurID e PIN). A busca de uma senha de root implicou a inserção de uma justificativa (geralmente um link para um número de ticket da Remedy (TM)) e acessos onde periodicamente auditados. Uma das poucas razões aceitáveis para usar a senha raiz diretamente foi nos casos em que um sistema foi parado em fsck durante o processo de inicialização ... e sulogin estava exigindo uma senha raiz real para executar manualmente a verificação do sistema de arquivos e processos de reparo. (Houve alguma discussão sobre métodos alternativos para isso - que são relativamente fáceis para o Linux, mas ficam muito mais difíceis à medida que você tenta estender seus procedimentos para considerar os muitos sistemas herdados HP-UX, AIX e SunOS e Solaris mais antigos que ainda estavam em produção nesse ambiente).
Existem casos-chave em que uma senha root é necessária --- ou pelo menos é a melhor alternativa disponível. Mantê-lo disponível, ao mesmo tempo em que o torna suficientemente robusto contra os tipos de ameaças que você pode prever, geralmente é sua melhor estratégia.
Outro site que conheço tem uma abordagem bastante elegante para o gerenciamento descentralizado de contas. Eles possuem pacotes user-* e sudo- * (pense em RPMs) que são instalados nos sistemas usando os procedimentos normais de gerenciamento de pacotes e a infraestrutura de automação. No caso deles, o pacote sudo- * tem uma dependência no pacote user-* correspondente. Isso é bom porque permite ter clusters de máquinas com contas localizadas (todas as contas são administradores, desenvolvedores, equipe de suporte ou contas "headless") e elimina a dependência de LDAP / NIS ou outros serviços de identidade e autenticação em rede. (Isso reduz o acoplamento entre os sistemas, tornando-os significativamente mais robustos).
Um pensamento que eu gosto sobre essa abordagem é que dá flexibilidade. Qualquer pessoa com acesso sudo pode emitir um comando para adicionar um usuário normal ou outra conta de usuário sudo . Então, se estou trabalhando em um ticket, qualquer pessoa que já tenha acesso a um sistema pode facilmente me dar acesso. Não há atrasos enquanto um ticket para me adicionar a alguma lista de controle de acesso em alguns bancos de dados centrais tritura através de algum processo de aprovação centralizado e finalmente propaga uma mudança de volta para o sistema em questão. Qualquer um dos sudo -ers autorizados no sistema pode me dar acesso e depois me remover. (Sim, se eu fosse mal e eles me caíssem sudo Eu poderia modificar coisas maliciosamente para manter o acesso ... na verdade, há algumas coisas que eu poderia fazer como um usuário normal para manter o acesso após essa remoção. No entanto, essa não é a ameaça que eles estão preocupados.Meu acesso ainda é limitado a um número relativamente menor de sistemas em geral, por isso o impacto de uma conta comprometida é ainda mais limitado do que a maioria dos esquemas semelhantes que eu vi.