Devo excluir as senhas dos usuários depois de configurar a autenticação de chave pública para SSH?

Se você tiver acesso root ao servidor e puder gerar novamente chaves ssh para seus usuários caso eles as percam

E

você tem certeza de que um usuário (como pessoa) não terá várias contas de usuário e precisará alternar entre aquelas em uma sessão SSH (bem, eles também podem abrir várias sessões SSH, se necessário)

E

eles nunca precisarão de acesso "físico" (via teclado + monitor ou console remoto para uma VM) ao servidor

E

nenhum usuário tem acesso por senha sudo(ou seja, eles não têm acesso sudo ou têm acesso sudo com NOPASSWD)

Acho que você vai ficar bem.

Temos muitos servidores em funcionamento configurados assim (apenas algumas contas precisam de acesso à VM via console remoto vmware, as outras se conectam apenas via SSH com autenticação pubkey).

Esta questão originalmente mencionou o passwd --delete <username> que não é seguro : com isso, o campo de senha criptografada /etc/shadowestará completamente vazio.

username::...

Se você configurou seu sshdpara recusar a autenticação de senha, então isso é seguro com SSH ... Você não quer isso.

adduser --disabled-passwdirá produzir uma /etc/shadowentrada onde o campo de senha criptografada é apenas um asterisco, ou seja

username:*:...

Esta é "uma senha criptografada que nunca pode ser inserida com sucesso", ou seja, isso significa que a conta é válida e tecnicamente permite logins, mas impossibilita a autenticação por senha de sucesso . Portanto, se você tiver outros serviços baseados em autenticação de senha em seu servidor, esse usuário será bloqueado para eles.

Apenas métodos de autenticação que usam algo diferente da senha de conta padrão (por exemplo, as chaves SSH) funcionarão para este usuário, para qualquer serviço que use os arquivos de senha do sistema neste sistema. Quando você precisa de um usuário que possa fazer login apenas com chaves SSH, é isso que você deseja.

Se você precisar definir uma conta existente para esse estado, poderá usar este comando:

echo 'username:*' | chpasswd -e

Há um terceiro valor especial para o campo de senha criptografada: adduser --disabled-login, então o campo conterá apenas um único ponto de exclamação.

username:!:...

Assim como o asterisco, isso impossibilita o sucesso da autenticação por senha, mas também tem um significado adicional: marca a senha como "bloqueada" para algumas ferramentas de administração. passwd -ltem o mesmo efeito ao prefixar o hash de senha existente com um ponto de exclamação, o que novamente torna a autenticação de senha impossível de usar.

Mas aqui está uma armadilha para os incautos: no ano de 2008, a versão de passwdcomando que vem do shadowpacote antigo foi alterada para redefinir passwd -lde "bloquear a conta" para apenas "bloquear a senha". O motivo declarado é "para compatibilidade com outra versão passwd".

Se você (como eu) aprendeu isso há muito tempo, pode ser uma surpresa desagradável. Também não ajuda questões que adduser(8)aparentemente ainda não estão cientes dessa distinção.

A parte que desabilita a conta para todos os métodos de autenticação é, na verdade, definir um valor de data de expiração de 1 para a conta: usermod --expiredate 1 <username>. Antes do ano de 2008, passwd -lisso se originava do shadowkit de origem usado para fazer isso , além de prefixar a senha com um ponto de exclamação - mas não faz mais isso.

O changelog do pacote Debian diz:

• debian/patches/494_passwd_lock-no_account_lock: Restaura o comportamento anterior de passwd -l (que mudou em #389183): bloqueia apenas a senha do usuário, não a conta do usuário. Também documente explicitamente as diferenças. Isso restaura um comportamento comum com as versões anteriores do passwd e com outras implementações. Fecha: #492307

Os históricos de bugs do bug 492307 e bug 389183 do Debian podem ser úteis para entender o pensamento por trás disso.