sudo não solicita senha e relata 3 tentativas incorretas de senha

2

O usuário smithj está listado no arquivo /etc/sudoers :

root ALL=(ALL) ALL
smithj ALL=(ALL) ALL

smithj entra no sistema via massa. Ele tenta sudo mas consegue isto:

sudo adduser jonesjp
Sorry, try again.
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts

Ele nunca é solicitado por sua senha. Isso é no CentOS 6.

Isso costumava funcionar, mas outro administrador fez algumas alterações desconhecidas que resultaram nisto e ele não está disponível.

    
por Paul Croarkin 04.10.2013 / 20:41

5 respostas

6

Algumas coisas para verificar:

Peça ao usuário que execute 'sudo -l'. Isso apenas pede ao sudo para lhe dizer quais permissões você tem. Se você não pode gerenciar isso, há uma questão fundamental de autenticação que provavelmente é separada do próprio sudo.

Compare /etc/pam.d/sudo com outros sistemas funcionais (ou backups).

Compare /etc/pam.d/system-auth com outros sistemas funcionais (ou backups). Mudanças sutis neste sistema podem introduzir problemas complicados de solução de problemas.

Veja o /etc/pam.d/system-auth e veja se o módulo pam_access.so está em uso. Se assim for, você vai querer verificar se smithj é permitido em /etc/security/access.conf (a menos que outro arquivo seja especificado pelo módulo pam). Um problema potencialmente complicado é se a conta tiver permissão para acessar um IP remoto, mas não localmente; isso acaba permitindo um login remoto, mas ações locais como cron jobs e sudo authentications falham.

O smithj está logando via senha? Ou via chaves? Verifique se eles podem fazer login com uma senha para ajudar a reduzir o problema. Se eles não conseguirem usar com sucesso sua senha em qualquer lugar, comece a olhar as mudanças em /etc/passwd, / etc / shadow, /etc/nsswitch.conf, e qualquer arquivo de configuração associado ao diretório que você está usando (talvez nenhum, talvez LDAP, NIS, AD).

Se você tiver um daemon de cache em execução, talvez nscd ou sssd, reinicie o daemon ('sudo service nscd restart'). Esses daemons são notórios por terem problemas.

    
por 05.10.2013 / 02:09
1

Eu tive este problema em um RH Como o sistema personalizado, o arquivo /etc/pam.d/sudo não existe.

Eu apenas o vinculo a /etc/pam.d/system-auth e funciona:

root@fws1:~ # ln -s /etc/pam.d/system-auth /etc/pam.d/sudo
    
por 07.06.2016 / 03:19
0

verifique seu arquivo /etc/pam.conf . para corrigir meus problemas, tive que adicionar

#############################
# SUDO service
#############################
sudo   auth       required        pam_authtok_get.so
sudo   auth       required        pam_dhkeys.so
sudo   auth       sufficient      pam_unix_auth.so
sudo   auth       required        pam_login_auth.so
sudo   account    required        pam_roles.so
sudo   account    required        pam_projects.so
sudo   account    required        pam_unix_account.so
sudo   account    required        pam_login_auth.so
    
por 25.03.2016 / 15:55
0

Verifique o arquivo /etc/nsswitch.conf para sudoers: files e, em seguida, verifique /etc/passwd e /etc/shadow para a conta do usuário.

Eu tinha o LDAP configurado e o usuário não existia em arquivos locais, portanto, o erro como o servidor procurava no LDAP para autenticação.

A configuração do Sudo e do LDAP é um tópico completamente diferente.

    
por 16.11.2016 / 18:58
-1

Eu tive um problema semelhante ao compilar o sudo para o Linux do zero 7.9. Tendo pam não instalado corretamente, tive que recompilar o sudo --without-pam. Então resolvi o problema, é seguramente em segurança.

    
por 20.05.2016 / 21:54

Tags