As a privileged user I am trying to set the sudo password to another then the one used at login.

I have done some research but have not found an answer. Does sudo support that kind of configuration?

If you ever lose your password, you lose everything. Someone could log in and promote himself to root with the same password.

sudo has an option to ask for root password instead of invoked user password, (rootpw), but sharing root password is definitely not an option, that is why we set up sudo.

I did config 2FA in the past, it worked great, but also defeats the automation purpose. For example if you want to execute a privileged command across a dozen of servers with an expect script, adding 2FA doesn't allow you to do that.

The closest solution I have found is to only allow SSH private key and setup pass-phrase with a key which differs from the sudo (login) password. Still, it is not comfy, because in an emergency situation you can't login with a PC where it doesn't have that key.

  • 1
    Why do you need this exactly? Maybe the problem is somewhere else. Wouldn't be better to have dual-factor authentication for logging into system with a privileged account and then have 'NOPASSWD', so that sudo does not ask for password? Then you should have of course a separate emergency local account with strong password to be able to login when network is down (no ssh access).
    – jirib
    Oct 11 '13 at 13:33

If you want to ask for the root password, as opposed to the user's password, there are options that you can put in /etc/sudoers. rootpw in particular will make it ask for the root password. There is runaspw and targetpw as well; see the sudoers(5) manpage for details.

Other than that, sudo does its authentication (like everything else) through PAM. PAM supports per-application configuration. Sudo's config is in (at least on my Debian system) /etc/pam.d/sudo, and looks like this:

$ cat sudo 

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

In other words, by default, it authenticates like everything else on the system. You can change that @include common-auth line, and have PAM (and thus sudo) use an alternate password source. The non-commented-out lines in common-auth look something like (by default, this will be different if you're using e.g., LDAP):

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

You could use e.g., pam_userdb.so instead of pam_unix.so, and store your alternate passwords in a Berkeley DB database.


I created the directory /var/local/sudopass, owner/group root:shadow, mode 2750. Inside it, I went ahead and created a password database file using db5.1_load (which is the version of Berkeley DB in use on Debian Wheezy):

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

That hash was generated with mkpasswd -m des, using the password "password". Very highly secure! (Unfortunately, pam_userdb seems to not support anything better than the ancient crypt(3) hashing).

Now, edit /etc/pam.d/sudo and remove the @include common-auth line, and instead put this in place:

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

Note that pam_userdb adds a .db extension to the passed database, so you must leave the .db off.

According to dannysauer in a comment, you may need to make the same edit to /etc/pam.d/sudo-i as well.

Now, to sudo, I must use password instead of my real login password:

anthony@sudotest:~$ sudo -K
anthony@sudotest:~$ sudo echo -e '\nit worked'
[sudo] password for anthony: passwordRETURN

it worked
  • Make sure to also configure "sudo-i", which newer versions of sudo often use for "sudo -i" (if the vendor hasn't changed something).
    – dannysauer
    Oct 11 '13 at 21:20
  • Can you elaborate on the PAM config pls? Oct 14 '13 at 8:58
  • @ShâuShắc I've added an example, including PAM config changes.
    – derobert
    Oct 14 '13 at 17:35
  • Thanks. But I dont find db51-utils anywhere in Redhat/centos or sources, is it only available in Debian variants? Oct 15 '13 at 5:01
  • 3
    The "the ancient crypt(3) hashing" on modern versions of glibc has support for sha-512, eg. mkpasswd -m sha-512. pam_userdb.so can handle these just fine. Jul 19 '17 at 17:37

For Redhat/Centos, the requirement can be achieved with following steps:

Create custom user and pass:

# db_load -t hash -T /usr/local/etc/passwd.db

Edit the sudo pam.d file so that it looks like:

$ 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

Im still looking for the way to config, so that only a certain user/group must be authen by this custom method, others still can be authen by the normal system-auth method. Can anyone give me some advises?

  • You should be able to do this with the full action syntax in PAM. e.g., [user_unknown=ignore,success=ok,default=bad]... but you'll have to play with that (and read the PAM docs) to get it right
    – derobert
    Oct 18 '13 at 21:06
  • This could also be accomplished using pam_succeed_if to skip one module if the user is in one of a list of groups, or to skip two modules if not.
    – dannysauer
    Jun 17 '15 at 19:15
  • So, something generally like this: /// auth [success=ignore default=1] pam_succeed_if.so user in danny:frank /// auth sufficient danny_frank_module.so /// auth sufficient not_danny_frank.so
    – dannysauer
    Jun 17 '15 at 19:15

I don't think sudo supports such a setup. The purpose of the sudo password prompt is to ensure that the person issuing the sudo command is the same person that is logged in, and the easiest way to do that is to ask for the currently logged in user to re-authenticate themselves.

In other words, the purpose of the sudo password prompt is not to establish authority, it is to establish identity. Based on the established identity and the sudo configuration, a decision can be made whether the user in question has the necessary authority or access rights.

  • 3
    Sudo doesn't (except in the case that you want to ask the root password, or a particular user, or the target user's password), but PAM does. And sudo uses PAM.
    – derobert
    Oct 11 '13 at 15:56

Your concern is that your account password can be disclosed. The solution is to not use the login password in a way that it can be disclosed. With ssh, the password is encrypted on the wire, so it's fine. People turn off password auth with ssh to prevent password guessing attacks, not to protect password confidentiality. If you're using the same account password for anything else, make sure that you're using a secure, encrypted channel to provide the password. If you're worried about a keylogger or whatever, stop using untrusted machines to log in.

If someone can get your ssh password, they can probably also get the alternate sudo password, so you're better off investing time into making your connections more secure than spending time just making things more complicated just for the illusion of more security.


I don’t have immediate access to a system where I can test this and work out the details, but I have an idea:

  • (Assume your normal login account is shau.)
  • Create a second account: shau2.  (I’m not sure whether you want it to have the same UID as shau.)
  • Configure shau2 to have sudo privileges with NOPASSWD.
  • Set up an alias or a shell script to do su shau2 -c sudo "$@".  This should ask for shau2’s password.  If that is entered correctly, it will run sudo as shau2 (which should not ask for a password).
  • Remove shau’s sudo privileges.

Unfortunately, you would have to repeat this for every user who has sudo privileges.


Thank you @Shâu Shắc for the answer! That solution also works for LinuxMint 17.1 Cinnamon 32bit (I've only installed db-util package in order to run db_load).

But I am very confused with the resultant passwd.db file. I've did the same as in your answer (but used david and jones, they look more eye-catching):

# db_load -t hash -T /usr/local/etc/passwd.db

But entered credentials are stored inside hash file as plain text:

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

You can also see david and jones via mcedit:

enter image description here

Yes, it's possible to restrict permissions of /usr/local/etc/passwd.db. But anyway, username and password stored as plain text are bad.

Even with separate sudo password there are some potential security holes (by default distro setup). Thus, separate password is not applicable for su (so it is possible to start root session using su and login password). Also separate password is not respected by Policy Kit (it is possible to start Synaptic using synaptic-pkexec and login password. Then delete packages...). These issues can be eliminated by additional tuning of configuration files.

In general seems that secure separate sudo password can be achieved only with aid of custom PAM module (perhaps, such module will compare password and SHA-512 hash read from file) or SELinux functionality.

PS: sorry, it should be a comment. But it goes as answer because of text format. Thanks for understanding.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.