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

É 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?

ubuntu ssh security password sftp lonix
fonte

Contanto que essas contas não sejam de usuários reais ou que eles não precisem da senha de sudoacesso (em virtude de não terem permissões de sudo ou de permissão de sudo NOPASSWD), 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.

Doktor J

Respostas:

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

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)

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

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).

Mr Shunz
fonte

Eu também acrescentaria "você sabe que os usuários nunca terão que acessar o sistema a partir de sistemas remotos que não possuem sua chave SSH privada". E "Você está disposto a lidar com usuários que se deparam com uma situação em que não pensou".

Andrew Henle

A primeira condição é IMO desnecessária. Seus usuários devem criar suas próprias chaves. Você apenas autoriza as chaves públicas delas, conforme elas as entregam a você. Se eles perderem uma chave, apenas gerarão outra e você substituirá a antiga no servidor.

Christophe Drevet-Droguet

@AndrewHenle Esse é um bom argumento, no entanto, se o sshd apresentar PasswordAuthentication noum problema diferente (o usuário não conseguiria fazer login).

lonix

"Nunca" é tanto tempo. O administrador pode facilmente adicionar novamente a autenticação de senha, se necessário.

Hyde

Bem, a pergunta está claramente relacionada a contas que definitivamente não (e provavelmente não deveriam) fazer login, como contas de sistema usadas por serviços específicos ou usuários somente de sftp. A questão também afirma que os usuários não têm shell de logon. Para esses tipos de usuários, acho aconselhável desabilitar explicitamente o login via senha.

Christian Gawron

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.

telcoM
fonte

Obrigado pelo aviso ... Vou editar a pergunta para que ninguém cometa esse erro!

lonix

Seu aviso também se aplica ao caso em que eu uso adduser --disabled-passwd- por isso, se algum outro serviço permitir autenticação por senha, o usuário poderá efetuar login sem uma senha?

lonix 04/04/19

Não, adduser --disabled-passwordespecificamente torna impossível a autenticação de senha para ter sucesso nessa conta.

telcoM 04/04/19

Como a exclusão da senha parece tão inocente, mas é tão perigosa, sugiro alternar o parágrafo com o parágrafo sobre o uso, *para que seja a primeira coisa que as pessoas leem.

Captain Man

Uau, isso é uma surpresa desagradável esperando para acontecer ... e, como de costume, aparentemente há um problema de compatibilidade a ser responsabilizado por isso. Ele apareceu no passwdcódigo-fonte em 2008. Você não gosta quando algo que você aprendeu uma vez e depois se baseou não é mais?

telcoM