A resposta curta é que quanto menor o seu perfil de ataque, melhor. Sempre. Se você não precisar dele ou puder usar uma alternativa como sudo ou su, não ative o login root.
Um grande argumento a favor da desativação do root e do uso do sudo / su é que você pode rastrear quem está fazendo o quê. Um usuário - um login. Nunca compartilhe contas.
O argumento nesse link parece ser específico para login local, em vez de ssh.
Eu cito o segundo ponto de Dennis, mais:
Permitir login root via SSH também significa que root é passível de ataque por senha de força bruta.
Como o root está sempre lá e a recompensa é tão alta, é um alvo prioritário. O nome de usuário teria que ser adivinhado primeiro, o que adiciona algumas ordens de magnitude à dificuldade do problema.
Nunca desative a conta root se você não tiver acesso ao console. Se o seu sistema de arquivos for preenchido e a inicialização falhar enquanto o / etc / nologin é criado, somente a conta root poderá efetuar login na máquina.
Dito isto, se você tiver acesso ao console para lidar com essas situações, o fechamento da conta root poderá lhe poupar algumas dores de cabeça, já que ninguém conseguirá acessar a conta root usando um ataque de dicionário (minha experiência é que eles são constantes nos dias de hoje - alguém está sempre tentando). Outras coisas que você pode pensar em fazer:
Cumprimentos,
João Miguel Neves
É sempre melhor desativar o login root via SSH.
Existem sistemas PKI (por exemplo, chaves públicas com SSH) que foram comprometidos. O SSH já possuía falhas de autenticação remota anteriormente que permitiam a ocorrência de um comprometimento de raiz. As PKIs de software são notoriamente mais fracas do que as PKIs baseadas em hardware ... se o seu computador host estiver comprometido, o servidor de destino também poderá cair facilmente. Ou pode haver falhas novas encontradas no SSH. Ao limitar o login da raiz, você também pode estender o período de tempo de que um invasor precisa para realizar o escalonamento de privilégios.
Historicamente, muitos administradores usavam hosts de bastiões (basicamente gateways) para entrar em uma rede e, em seguida, pulavam para caixas depois. Usar uma distro de alta segurança (por exemplo, o OpenBSD) como um host de bastiões, em conjunto com diferentes sistemas operacionais, fornece defesa em profundidade e defesa na diversidade (uma vulnerabilidade menos provável de comprometer toda a rede).
Por favor, considere também uma conexão fora de banda com a sua rede, como um concentrador serial, um comutador serial ou outro. Isso fornecerá a disponibilidade de backup de sua interface administrativa, se necessário.
Como sou paranóico e estou em segurança, é mais provável que eu use uma VPN IPSEC ou uma VPN Type1 e, em seguida, execute o SSH em cima dele, sem nenhuma exposição à Internet do SSH. Colocar a VPN em seu hardware de rede pode simplificar bastante isso na implementação.
Devemos examinar essa questão de diferentes pontos.
O Ubuntu desabilita a conta root por padrão, o que significa que você não pode fazer login via SSH com root. Mas, permite que qualquer pessoa com um CD do Ubuntu possa inicializar e obter acesso root.
Acredito que o melhor compromisso é ativar a conta root com acesso SSH desativado. Se você precisa de acesso root com o SSH, faça o login com um usuário normal e use o sudo. Desta forma, assegura o acesso à caixa, sem comprometer a segurança remota.
Eu diria que sim, o login como root deve ser desativado para fins de auditoria. Se você é o único administrador do sistema nesta máquina, é trivial determinar quem fez o quê para quem, mas se dez pessoas estiverem autorizadas a administrar a caixa e todas elas souberem a senha raiz, teremos um problema.
Se o root está ativado ou não, nem a raiz nem qualquer outro usuário deve ter permissão para efetuar login remotamente com uma senha. O fail2ban não faz nada contra um botnet de força bruta lenta e não funciona com o IPv6. (A versão 1 do protocolo ssh e implementações mais antigas da versão 2 eram vulneráveis a ataques de adivinhação de senhas contra prompts de senha interativos dentro da sessão ssh, mas isso parece não ser mais o caso com uma implementação ssh suficientemente recente.)