Por que se preocupar em parar o 'root' do login do ssh?

Question

A melhor prática é remover a capacidade de 'root' para efetuar login no ssh. No entanto, eu preciso executar alguns comandos Ansible e atualmente estou conectando através de um usuário chamado "amdhske" e então configurei este usuário para não precisar digitar a senha para fazer sudo caso contrário, o Ansible precisa manter a senha do usuário por perto. / p>

Então, qual é o objetivo de desativar o acesso root neste caso? Qualquer invasor que entrar na conta de usuário "amdhske" pelo ssh poderá, então, sudo heck sair do servidor. Eu estou supondo que a única vantagem aqui é que ao escolher um longo nome de usuário aleatório, é altamente improvável que um invasor saiba sobre ele, enquanto 'root' é o nome de usuário padrão para, bem, 'root'. Existe algum outro motivo?

    

Answer 1

Bastante fácil. Duas razões:

1. Você pode limitar o que pode sudo sem senha com seu usuário. Você acabou de inserir a configuração correta nos arquivos sudoers:

   amdhske ALL=NOPASSWD: /usr/bin/somecommand
   

Se você fizer login com root, terá todas as permissões para fazer qualquer coisa.

2. Todo script kiddie on earth sabe que o nome da sua conta de superusuário é root. Então, qual nome de usuário você acha que eles vão tentar força bruta, etc, para o seu sistema? Certo, raiz.

É por isso que é uma boa prática de segurança desativar o login root do ssh.

    

Answer 2

Para resolver o problema com "Ansible" sem desabilitar a pergunta de senha para sudo , você pode usar um comando trivial como sudo ls e continuar com sudo Ansible . No entanto, isso é apenas uma solução e você sudo expira depois de algum tempo, por isso pode não resolver completamente o problema.

PS. Eu entendo que isso não está resolvendo a pergunta direta do OP, mas estou tentando abordar seu problema raiz (trocadilho intencional).

    

Answer 3

Há várias coisas acontecendo aqui, e eu posso sentir falta de algumas, mas aqui vai.

1. Segurança por obscuridade: verifique seu log de autenticação a qualquer momento. Provavelmente, existem centenas de tentativas de login raiz por scripts automatizados todos os dias, e o não uso do login por esse usuário bloqueia alguns resultados baixos.

2. Políticas herdadas: não é um problema tão grande quanto a autenticação baseada em chave, mas com modelos de autenticação mais antigos era uma prática incrivelmente ruim deixar o login de raiz aberto. Essas práticas recomendadas não mudaram porque não há benefício real para o login raiz, em primeiro lugar.

3. Registro em log: se cada usuário tiver sua própria conta, você poderá dizer com mais facilidade quem fez o quê em seu sistema.

Além disso, o sudo sem senha teria sido considerado uma prática muito ruim, não muito tempo atrás. É somente na era da autenticação baseada em chave que isso se tornou útil e seguro. Os usuários nem sempre conhecem suas senhas para que não possam fornecê-las, mesmo se solicitadas.