Esta questão originalmente mencionou passwd --delete <username> que não é seguro : com isso, o campo de senha criptografada em /etc/shadow ficará completamente vazio.
username::...
Se você configurou seu sshd para recusar a autenticação de senha, isso é seguro com o SSH ... Mas se qualquer serviço no seu sistema usa autenticação por senha e não está configurado para rejeitar nulo senhas, isso permite acesso sem senha! Você não quer isso.
adduser --disabled-passwd produzirá uma entrada /etc/shadow , em que o campo de senha criptografada é apenas um asterisco, ou seja,
username:*:...
Esta é "uma senha criptografada que nunca pode ser inserida com sucesso", ou seja, a conta é válida e tecnicamente permite logins, mas torna a autenticação pela senha impossível de ser bem-sucedida . Portanto, se você tiver outros serviços baseados em autenticação de senha em seu servidor, esse usuário será bloqueado deles.
Somente os métodos de autenticação que usam algo diferente da senha da 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 efetuar login apenas com chaves SSH, é isso que você quer.
Se você precisar definir uma conta existente para esse estado, poderá usar este comando:
echo 'username:*' | chpasswd -e
Existe 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:!:...
Como o asterisco, isso torna a autenticação de senha impossível de ser bem-sucedida, mas também tem um significado adicional: marca a senha como "bloqueada" para algumas ferramentas de administração. passwd -l tem praticamente o mesmo efeito prefixando o hash de senha existente com um ponto de exclamação, o que torna a autenticação de senha impossível de usar novamente.
Mas aqui está uma armadilha para os desavisados: no ano de 2008, a versão do comando passwd que vem do antigo pacote shadow foi alterada para redefinir passwd -l de "bloquear a conta" para apenas "bloquear a senha". O motivo declarado é "para compatibilidade com outra versão do passwd ".
Se você (como eu) aprendeu isso há muito tempo, pode ser uma surpresa desagradável. Não ajuda em nada que adduser(8) aparentemente ainda não esteja ciente dessa distinção.
A parte que desativa a conta para todos os métodos de autenticação está, na verdade, definindo um valor de data de expiração de 1 para a conta: usermod --expiredate 1 <username> . Antes do ano de 2008, passwd -l que se origina do kit de código shadow 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: Restore the
previous
behavior of passwd -l (which changed in #389183): only lock the user's
password, not the user's account. Also explicitly document the
differences. This restores a behavior common with the previous versions of
passwd and with other implementations. Closes: #492307
Os históricos de bugs para o bug da Debian 492307 e bug 389183 pode ser útil para entender o pensamento por trás disso.