Defina a senha do sudo de maneira diferente do login um

Como usuário privilegiado, estou tentando definir a sudosenha para outra que não seja a usada no login.

Eu fiz algumas pesquisas, mas não encontrei uma resposta. Será que sudosuporte esse tipo de configuração?

Se você perder sua senha, você perde tudo. Alguém poderia fazer login e promover-se rootcom a mesma senha.

sudotem uma opção para solicitar rootsenha em vez da senha de usuário invocada, ( rootpw), mas o compartilhamento de rootsenha definitivamente não é uma opção, é por isso que configuramos sudo.

Eu fiz config 2FAno passado, funcionou muito bem, mas também derrota o objetivo de automação. Por exemplo, se você deseja executar um comando privilegiado em uma dúzia de servidores com um expectscript, a adição 2FAnão permite que você faça isso.

A solução mais próxima que encontrei é permitir apenas a chave privada SSH e a frase secreta de configuração com uma chave diferente da sudosenha (login). Ainda assim, não é confortável, porque em uma situação de emergência você não pode fazer login com um PC onde não possui essa chave.

Se você deseja solicitar a senha root, em oposição à senha do usuário, há opções que você pode inserir /etc/sudoers. rootpwem particular, fará com que solicite a senha de root. Existe runaspwe targetpwtambém; veja a página de manual do sudoers (5) para detalhes.

Fora isso, o sudo faz sua autenticação (como tudo o mais) através do PAM. O PAM suporta a configuração por aplicativo. A configuração do Sudo está (pelo menos no meu sistema Debian) /etc/pam.d/sudoe se parece com isto:

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

Em outras palavras, por padrão, ele se autentica como tudo no sistema. Você pode alterar essa @include common-authlinha e fazer com que o PAM (e, portanto, o sudo) use uma fonte de senha alternativa. As linhas não comentadas em common-auth se parecem com (por padrão, isso será diferente se você estiver usando, por exemplo, LDAP):

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Você pode usar, por exemplo, em pam_userdb.sovez de pam_unix.so, e armazenar suas senhas alternativas em um banco de dados Berkeley DB.

exemplo

Eu criei o diretório /var/local/sudopass, proprietário / grupo root:shadow, modo 2750. Dentro dele, criei um arquivo de banco de dados de senhas usando db5.1_load(que é a versão do Berkeley DB em uso no Debian Wheezy):

# umask 0027
# db5.1_load -h /var/local/sudopass -t hash -T passwd.db
anthony
WMaEFvCFEFplI
^D

Esse hash foi gerado com mkpasswd -m des, usando a senha "password". Muito altamente seguro! (Infelizmente, o pam_userdb parece não suportar nada melhor que o crypt(3)hash antigo ).

Agora, edite /etc/pam.d/sudoe remova a @include common-authlinha e, em vez disso, coloque isso no lugar:

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Observe que o pam_userdb adiciona uma .dbextensão ao banco de dados passado, portanto, você deve deixá- .dblo desativado.

De acordo com dannysauer em um comentário , talvez você precise fazer a mesma edição /etc/pam.d/sudo-itambém.

Agora, para sudo, devo usar em passwordvez da minha senha de login real:

anthony @ sudotest: ~ $ sudo -K
anthony @ sudotest: ~ $ sudo echo -e '\ nit funcionou'
[sudo] senha para anthony: passwordRETURN

funcionou

Para Redhat / Centos, o requisito pode ser alcançado com as seguintes etapas:

Crie usuário personalizado e passe:

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

Edite o arquivo sudo pam.d para que fique parecido com:

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

Ainda estou procurando a maneira de configurar, para que apenas um determinado usuário / grupo seja autenticado por esse método personalizado, outros ainda possam ser autenticados pelo método normal de autenticação do sistema. Alguém pode me dar alguns conselhos?

Eu não acho que o sudo suporte essa configuração. O objetivo do prompt da senha do sudo é garantir que a pessoa que emite o comando sudo seja a mesma pessoa que efetuou login, e a maneira mais fácil de fazer isso é solicitar que o usuário conectado no momento se autentique novamente.

Em outras palavras, o objetivo do prompt de senha do sudo não é estabelecer autoridade , é estabelecer identidade . Com base na identidade estabelecida e na configuração do sudo, é possível decidir se o usuário em questão possui a autoridade ou direitos de acesso necessários.

Sua preocupação é que a senha da sua conta possa ser divulgada. A solução é não usar a senha de login de uma maneira que possa ser divulgada. Com o ssh, a senha é criptografada na conexão, então tudo bem. As pessoas desativam a autenticação de senha com ssh para impedir ataques de adivinhação de senha, não para proteger a confidencialidade da senha. Se você estiver usando a mesma senha da conta para qualquer outra coisa, verifique se está usando um canal criptografado e seguro para fornecer a senha. Se você estiver preocupado com um keylogger ou qualquer outra coisa, pare de usar máquinas não confiáveis ​​para fazer login.

Se alguém pode obter sua senha ssh, provavelmente também pode obter a senha sudo alternativa, portanto, é melhor investir tempo para tornar suas conexões mais seguras do que gastar tempo apenas complicando as coisas apenas pela ilusão de mais segurança.

Não tenho acesso imediato a um sistema onde posso testar isso e resolver os detalhes, mas tenho uma ideia:

• (Suponha que sua conta de login normal seja shau.)
• Criar uma segunda conta: shau2. (Não tenho certeza se você deseja que ele tenha o mesmo UID que shau.)
• Configure shau2para ter privilégios sudo com NOPASSWD.
• Configure um alias ou um script de shell para fazer su shau2 -c sudo "$@". Isso deve pedir shau2a senha de. Se isso for inserido corretamente, ele será executado sudocomo shau2 (que não deve solicitar uma senha).
• Remova shauos privilégios sudo.

Infelizmente, você teria que repetir isso para todos os usuários com privilégios de sudo.

Obrigado @ Shâu Shắc pela resposta ! Essa solução também funciona para o LinuxMint 17.1 Cinnamon 32bit (eu instalei apenas o db-utilpacote para executar db_load).

Mas estou muito confuso com o passwd.dbarquivo resultante . Fiz o mesmo que em sua resposta (mas usei David e Jones , eles parecem mais atraentes):

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

Mas as credenciais inseridas são armazenadas dentro do arquivo hash como texto sem formatação:

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

Você também pode ver david e jones via mcedit :

Sim, é possível restringir as permissões de /usr/local/etc/passwd.db. Mas de qualquer maneira, nome de usuário e senha armazenados como texto sem formatação são ruins.

Mesmo com a senha sudo separada, existem algumas falhas de segurança em potencial (por configuração padrão da distribuição). Portanto, uma senha separada não é aplicável ao su (portanto, é possível iniciar a sessão raiz usando uma susenha de login). Além disso, a senha separada não é respeitada pelo Kit de Políticas (é possível iniciar o Synaptic usando a synaptic-pkexecsenha de login. Depois, exclua os pacotes ...). Esses problemas podem ser eliminados pelo ajuste adicional dos arquivos de configuração.

Em geral, parece que uma senha sudo separada segura pode ser obtida apenas com a ajuda do módulo PAM personalizado (talvez, esse módulo compare a senha e a leitura de hash SHA-512 do arquivo) ou a funcionalidade SELinux.

PS: desculpe, deve ser um comentário. Mas funciona como resposta por causa do formato de texto. Obrigado pela compreensão.