É melhor usar chaves públicas para SSH. Então o meu sshd_configtem PasswordAuthentication no.
Alguns usuários nunca efetuam login, por exemplo, um usuário sftp com shell /usr/sbin/nologin. Ou uma conta do sistema.
Para que eu possa criar esse usuário sem uma senha com adduser gary --shell /usr/sbin/nologin --disabled-password.
Essa é uma boa / má ideia? Existem ramificações que eu não considerei?
Respostas:
Se você tiver acesso root ao servidor e puder gerar novamente as chaves ssh para seus usuários, caso elas as percam
E
você tem certeza de que um usuário (como pessoa) não terá várias contas de usuário e precisa alternar entre aquelas em uma sessão SSH (bem, ele também pode 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 sudoacesso limitado por senha (ou seja, eles não têm acesso ao sudo, ou têm acesso ao sudo NOPASSWD)
Eu acho que você vai ser bom.
Temos muitos servidores em funcionamento configurados como este (apenas algumas contas precisam acessar a VM via console remoto vmware, outras se conectam apenas via SSH com pubkey auth).
PasswordAuthentication noum problema diferente (o usuário não conseguiria fazer login).
Esta pergunta mencionou originalmente o passwd --delete <username> que não é seguro : com isso, o campo de senha criptografada /etc/shadowestará completamente vazio.
username::...
Se você configurou sua opção sshdpara recusar a autenticação de senha, isso é seguro com o SSH ... Mas se qualquer outro serviço em seu sistema usar autenticação por senha e não estiver configurado para rejeitar senhas nulas, isso permitirá o acesso sem uma senha! Você não quer isso.
adduser --disabled-passwdproduzirá uma /etc/shadowentrada em que o campo de senha criptografada é apenas um asterisco, ou seja,
username:*:...
Esta é "uma senha criptografada que nunca pode ser inserida com êxito", ou seja, isso significa que a conta é válida e permite logins tecnicamente, mas torna impossível a autenticação por senha . Portanto, se você tiver outros serviços baseados em autenticação de senha no servidor, esse usuário será bloqueado.
Somente 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ê 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-loginentão o campo conterá apenas um único ponto de exclamação.
username:!:...
Como o asterisco, isso torna impossível a autenticação da senha, mas também tem um significado adicional: marca a senha como "bloqueada" para algumas ferramentas administrativas. passwd -ltem o mesmo efeito prefixando o hash da senha existente com um ponto de exclamação, o que novamente torna impossível a autenticação da senha.
Mas aqui está uma armadilha para os incautos: no ano de 2008, a versão do 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 do passwd".
Se você (como eu) aprendeu isso há muito tempo, pode ser uma surpresa desagradável. Também não ajuda a questões que adduser(8)aparentemente ainda não estão cientes dessa distinção.
A parte que desativa a conta para todos os métodos de autenticação é realmente definir um valor de data de expiração de 1 para a conta: usermod --expiredate 1 <username>. Antes do ano de 2008, passwd -lele 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 o faz mais.
O changelog do pacote Debian diz:
- debian / patches / 494_passwd_lock-no_account_lock: Restaura o comportamento anterior de passwd -l (que foi alterado no # 389183): bloqueie 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
As histórias de bugs para Debian bug 492307 e bug 389183 pode ser útil para compreender o pensamento por trás disso.
adduser --disabled-passwd- por isso, se algum outro serviço permitir autenticação por senha, o usuário poderá efetuar login sem uma senha?
adduser --disabled-passwordespecificamente torna impossível a autenticação de senha para ter sucesso nessa conta.
*para que seja a primeira coisa que as pessoas leem.
passwdcódigo-fonte em 2008. Você não gosta quando algo que você aprendeu uma vez e depois se baseou não é mais?
sudoacesso (em virtude de não terem permissões de sudo ou de permissão de sudoNOPASSWD), a resposta que você selecionou deve ser adequada. Enviei uma edição dessa resposta para incluir a preocupação com o sudo, mas imaginei que eu o chamaria aqui enquanto isso.