Graphical authentication works; why does sudo say my password is wrong?

Solution 1:

First... A Probable Workaround

It's likely you can work around this problem until it's solved by using pkexec in place of sudo when you want to run a command as root. See "Maybe sudo is Broken" below for details.

It's not definite that this will work. If not, one of the other solutions or workarounds here might. If not, this will probably still help you gather information about the problem, which you can add to your question.

(People with this problem other than the asker of this question can create a new question with information about what happened when they tried the techniques here.)

The Basics of This Situation

Most of the time, when people report they cannot effectively enter their password for sudo in a terminal, but can authenticate with it graphically at least some of the time, it is because they don't realize that no placeholder characters (like *) are supposed to appear. Here, it seems that is not the case. If you entered your password correctly and in full before pressing Enter, there really is some problem.

To figure out what it is, more information is necessary. Here are some possible causes of sudo not accepting the password in the terminal even though you can enter it graphically to install software.

1. Maybe the Password is Blank

^{Suggested by Bruno Pereira.}

If your password is blank, i.e., zero characters long, i.e., you just press Enter when asked for your password, change it to something that is not blank.

It's likely you can change your password in System Settings (since you can perform at least some administrative tasks graphically). If that doesn't work, and you can install software, you can install gnome-admin-tools , run users-admin (another graphical utility), and change your password that way.

If that doesn't work, try running pkexec passwd $USER. (pkexec will prompt graphically for your password if a GUI is available and working, even when used to run CLI commands.)

If that doesn't work, try any of these methods; if that doesn't work, try this method.

2. Maybe the Password Contains Weird Characters

If your password contains characters other than the numerals (0-9), capital (A-Z) and lower-case (a-z) letters with no accent marks, and punctuation that appear on a US/English keyboard, change it so it does. If you're using a different locale, then to be safe, you can (temporarily) change your locale as well.

Spaces are ordinarily fine in passwords but as you're having problems it makes sense to try it without them. They're relatively uncommon, so there could be an undiscovered bug triggered by a combination of having a password with spaces in it and some other condition.

3. Maybe the Password is Perfectly Ordinary, But Was Stored Wrong

Even if all one or more characters of your password are commonly used, it's still a good idea to change your password to see if it solves the problem. Also, if you change your password and it does not solve your problem, that is another important piece of information.

I've talked to people in this situation, where changing the password fixed the problem, even though there was nothing particularly wrong with or strange about it originally. I suspect that the problem might have to do with how the password is stored, but it could be that the underlying cause is coincidentally corrected by setting the password, or that the situation was (albeit repeatedly by different people) misreported to me, or that I misunderstood.

4. Maybe You're Not Typing What You Think You Are

Make sure your keyboard layout is what you think it is when you put in your password.

5. Maybe Your Terminal is Misinterpreting Input

Perhaps the password that is being seen is not what you're actually entering. To see if this is the case:

• Enter it in the terminal when not entering your password (don't "run" it, and still don't tell us what it is).

• Try it in a different terminal application. You're using Terminal; try xterm. (Press Alt+F2 and run xterm.)

• Try it on a virtual console. Press Ctrl+Alt+F1 and see if you can log in. Like when running sudo, it's normal for you not to see anything happening as you enter your password. Just type it in and press Enter when you're done.

  Whether that succeeds or fails, knowing if it worked provides useful information.

  Then try actually running sudo.

  To get back to the GUI, press Alt+F7.

6. Maybe sudo Works, But Not when Invoked from the Command Line

To check this, run gksudo xclock. You'll be prompted graphically for your password, but sudo will be used "under the hood."

If that works--that is, if a simple graphical clock application appears--then sudo works, but (assuming it also failed when you tried running it in another terminal app and in a virtual console), something is wrong with the way it is taking input from command-line interfaces.

7. Maybe CLI Password Authentication is Broken

This could occur if there is a common problem preventing sudo and other, different ways of asking for passwords on the command line, from working right.

Run su $USER -c 'echo Success'. You'll be prompted for your password. Type it in (again, it's normal to have nothing appear on the screen as you do), press Enter, and see if Success appears.

If you were unable to get past authentication there, then the problem affects both terminal-based sudo and terminal-based su.

8. Maybe sudo is Broken

Try running a command with PolicyKit: pkexec echo Success

A GUI window should come up and ask you for your password; if authentication succeeds, Success will appear in the terminal.

If this works, you have a workaround for the problem: use pkexec instead of sudo.

If sudo is broken, you might be able to fix it, depending on what is wrong with sudo:

8.1. Maybe the installation is messed up.

Try reinstalling sudo with:

pkexec apt-get update && pkexec apt-get --purge --reinstall sudo

That may fix a corrupted or misconfigured installation.

8.2. Maybe sudo is misconfigured in /etc/sudoers.

For misconfigurations relating to unexplained password authentication failures, check the Defaults lines in /etc/sudoers by running:

pkexec grep Defaults /etc/sudoers

In Ubuntu the output is normally:

Defaults    env_reset
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

If you see rootpw, runaspw, or targetpw, this means sudo is not necessarily asking for your password.

This is particularly likely if you are prompted [sudo] password for root: or [sudo] password for some-other-username instead of [sudo] password for your-username. But it's worth checking for in any case (as it's easy to check).

Even if you don't see any of those three ...pw terms, you still might see something wrong; if your output of pkexec grep Defaults /etc/sudoers is not the same as what's shown above, you should look into that (for example, you can include it when you edit your question to provide details about what happened when you tried all these techniques).

If this doesn't reveal anything, take a look at all of /etc/sudoers. You can use pkexec less /etc/sudoers or open the file in an editor with pkexec visudo. If you don't see anything wrong, I recommend still posting the contents of the file in your question.

If you find a problem in /etc/sudoers and know what has to be changed, you can edit it using pkexec visudo.

8.3. Maybe sudo is misconfigured in /etc/sudo.conf.

Normally on Ubuntu, /etc/sudo.conf does not exist. And that is good--it works normally in that situation. If /etc/sudo.conf does exist, sudo may be configured to work in a radically different way. (Or it might be configured to work exactly the same way, and have nothing to do with your problem. Or anything in between.)

If this file exists, regardless of what's in it, please provide its complete contents.

If /etc/sudo.conf exists, by default the only uncommented lines (i.e., the only lines that don't start with #) are:

Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so

This uses the sudoers module to control the security policy and interface of sudo. If any other module is used, things can be quite different, so that's very relevant information.

8.4. Maybe this is a PAM problem, presenting unusually.

This is kind of a stretch, but maybe sudo is configured to use pluggable authentication modules and its PAM configuration has a problem.

• This is a stretch because usually you are not asked to enter a password at all when this happens.

To check, run:

ls -ld /etc/pam.d
ls -l /etc/pam.d/sudo
cat /etc/pam.d/sudo

The text in the terminal should look like this:

$ ls -ld /etc/pam.d
drwxr-xr-x 2 root root 4096 Jan 16 01:44 /etc/pam.d
$ ls -l /etc/pam.d/sudo
-rw-r--r-- 1 root root 239 May 31  2012 /etc/pam.d/sudo
$ cat /etc/pam.d/sudo
#%PAM-1.0

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-auth
@include common-account
@include common-session-noninteractive

If any of the bold text differs at all, that suggests a problem.

I got this idea from the upstream sudo troubleshooting page (but that page does not suggest the problem will happen this way).

9. Maybe It's Something Else

Maybe none of the situations covers your problem. Or maybe the problem is that sudo is broken, but none of the sub-situations for that apply.

If that's the case, don't give up! (Unless you want to.)

Just provide as much more information as possible, including what happened when you tried each technique or diagnostic step. This will likely shed light on the problem.

_{This answer is moved, with slight modification, from this question (where it didn't really belong, as it's not clear the OP there really has this problem). Thanks to gertvdijk for helping me recognize the ambiguity there and suggesting this be posted elsewhere instead. (He is not responsible for any errors here, however.)}

Solution 2:

sudo wasn't accepting my password either. It was because I had added

auth required pam_tally.so per_user magic_root onerr=fail

to the top of /etc/pam.d/common_auth in an attempt to create a 10 minute delay after 3 failed password attempts. Removing that one line fixed my problem.

Solution 3:

Don't forget to check /var/log/auth.log to see what happens on your sudo-ing.

In my case I saw message sudo: PAM (sudo) illegal module type: i.

Googling by this message led me to the answer: by some reason when I installed Unity on my Ubuntu 18.04 and reconfigured lightdm, some code modified file /etc/pam.d/common-session-noninteractive. What I really saw in that file was just:

i#
# /etc/pam.d/common-session-noninteractive - session-related modules
# common to all non-interactive services
...

Yes, just little letter i as the first symbol in the file. It's shocking but somehow that happened!

I've rebooted the system in recovery mode (as root), deleted this i in file, and now sudo works fine!