User smithj is listed in the /etc/sudoers file:

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

smithj logs into the system via putty. He attempts to sudo but gets this:

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

He is never prompted for his password. This is on CentOS 6.

This used to work, but another admin made some unknown changes that resulted in this and he is not available.

  • 1
    What does /var/log/secure says?
    – dawud
    Oct 4, 2013 at 18:43
  • 1
    check SUDO_ASKPASS environment variable
    – kofemann
    Oct 4, 2013 at 18:48
  • /var/log/secure: Oct 4 14:50:58 CentBOx sudo: smithj : 3 incorrect password attempts ; TTY=pts/1 ; PWD=/home/smithj ; USER=root ; COMMAND=/usr/sbin/adduser jonesjp Oct 4, 2013 at 18:52
  • 1
    check for 'Path askpass'
    – kofemann
    Oct 4, 2013 at 19:51
  • 1
    What if you use a gui/X session or mobaxterm from windows? Also try sudo -D 9 -i
    – Jure1873
    Oct 6, 2013 at 16:19

5 Answers 5


Some things to check:

Have the user run 'sudo -l'. This just asks sudo to tell you what permissions you have. If you can't manage this, there's a fundamental issue authenticating that's probably separate from sudo itself.

Compare /etc/pam.d/sudo with other functional systems (or backups).

Compare /etc/pam.d/system-auth with other functional systems (or backups). Subtle changes to this system can introduce gnarly troubleshooting problems.

Look at /etc/pam.d/system-auth and see if the pam_access.so module is in use. If so, you'll want to check whether smithj is allowed in /etc/security/access.conf (unless another file is specified by the pam module). One potentially tricky problem is if the account is allowed access from a remote IP, but not locally; this ends up allowing a remote log in, but local actions like cron jobs and sudo authentications fail.

Is smithj logging in via password? Or via keys? Make sure they can log in with a password to help narrow the problem. If they can't successfully use their password anywhere, start looking at changes against /etc/passwd, /etc/shadow, /etc/nsswitch.conf, and any config files associated with the directory you're using (perhaps none, perhaps LDAP, NIS, AD).

If you have a caching daemon running, perhaps nscd or sssd, restart the daemon ('sudo service nscd restart'). These daemons are notorious for having problems.

  • 'sudo -l' produces: Sorry, try again. Sorry, try again. Sorry, try again. sudo: 3 incorrect password attempts Oct 5, 2013 at 16:55
  • He is logging in via putty with a password Oct 5, 2013 at 16:56
  • Is pam_access at play? Oct 6, 2013 at 1:31
  • The only references to pam_access are in /etc/pam.d/atd and /etc/pam.d/crond which have not changed Oct 7, 2013 at 20:32
  • Solved. The following two lines had been added to /etc/pam.d/system-auth-ac: auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900 auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900 Oct 8, 2013 at 11:40

I had this problem on a RH Like custom system, the file /etc/pam.d/sudo didn't exists.

I just link it to /etc/pam.d/system-auth and it works:

root@fws1:~ # ln -s /etc/pam.d/system-auth /etc/pam.d/sudo
  • For me the /etc/pam.d/sudo file did exit but just did not work for some reason. I moved it and created the symbolic link like you show and it worked.
    – Dave
    Mar 15 at 2:48

check your /etc/pam.conf file. to fix my issues I had to add

# 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
  • there should be a line break before every sodo command
    – mohi
    Mar 25, 2016 at 14:57

Check /etc/nsswitch.conf file for sudoers: files and then check /etc/passwd and /etc/shadow for the user account.

I had LDAP configured and the user did not exist in local files hence the error as the server was looking in LDAP for authentication.

Sudo and LDAP configuration is an entirely different topic.


I had a similar problem compiling sudo for Linux from scratch 7.9. Having pam not properly installed, I had to recompile sudo --without-pam. So I solved the problem, it is surely in security.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .