É aconselhável usar uma senha muito segura para usuários do sudo ao usar chaves SSH para login do servidor?

Question

Não estou perguntando como fazer nada aqui, em vez de tentar entender as práticas recomendadas e a maneira "certa" de lidar com a segurança do servidor. Para evitar ataques de senha de força bruta, eu tenho protegido meu servidor de várias maneiras, sendo uma delas SSH Keys protegidas por senha para login em qualquer usuário (agora é uma única caixa de desenvolvedor). Obviamente, sempre que um usuário precisar fazer o login, precisará acessar a chave e a senha para essa chave.

No entanto, estou tentando entender como devo lidar com uma senha do sistema para esse (ou qualquer) usuário específico, especificamente ao lidar com o sudo. Algumas perguntas:

• há valor em dar a cada usuário uma senha (para que ele possa usar o sudo)?
• em caso afirmativo, é um exagero usar uma senha insanamente segura para tal (ou seja, 384 bits +)
• supondo que a resposta acima seja não:
  • Como qualquer usuário pode se lembrar dessa senha toda vez que precisar executar um comando sudo (sim lastpass, dashlane, 1pass, etc são opções, mas ter que abrir / autenticar / encontrar e copiar essa senha realmente longa parece ser uma grande dor ass).
  • O que é seguro o suficiente para essas senhas e importa se os ataques de dicionário encontrariam a senha do sudo em 3 segundos de qualquer maneira?

Obrigado antecipadamente!

    

Answer 1

Eu vou pelo caminho oposto e uso o sudo sem senha.

% sudo ALL = (TODOS: TODOS) NOPASSWD: TODOS

Como você apontou, verifique se as chaves ssh do usuário têm uma frase secreta. Além disso, certifique-se de desativar a autenticação de senha para SSH.

Se você fez o acima, acho que esta configuração é muito funcional.

    

Answer 2

Ter uma senha no sudo não é apenas sobre autenticação, mas também uma interrupção para autorizar solicitações.

Se você copiar e colar em um script que contenha sudo rm -rf / passwordless, o sudo não o ajudará.

Há também a possibilidade de que um usuário em potencial se torne um alvo para escalonamento de privilégios por outro usuário, se o usuário mal-intencionado puder se tornar, de alguma forma, o usuário confiável que tem acesso sudo sem senha; digamos que o usuário confiável tenha um trabalho cron inócuo que execute um script para o qual o usuário mal intencionado tenha privilégios de gravação e ele altere o script para fazer outra coisa.

Isso pode não ser uma preocupação para você, mas observe que o prompt de senha impede que certos vetores de ataque se tornem realidade.