Set sudo password differently from login one

Question

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.

Answer 1

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 
#%PAM-1.0

@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.

example

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
anthony
WMaEFvCFEFplI
^D

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

Answer 2

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
user
pass
^d

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?

Answer 3

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.

Answer 4

My solution isn't any different then the excellently proposed ones.

However, I do include ALL commands for all steps taking out any guesswork or further reading.

I'm not against reading, just there are time when a pure reference is required. I hope others would find this useful.

I've tested this on Ubnutu 22.04.

I've installed db-util and whois (for mkpasswd):

sudo apt --yes install db_util whois

# Run this from your user
# Plaintext password
# Flavor is either sudo or sudo-i, recommended to test only on one first
PASSWD='password'; FLAVOR="sudo-i"
Uncomment next line to erase existing db and start from scratch:
sudo bash -c "[[ ! -r /var/local/sudopass/passwd.db ]] || rm /var/local/sudopass/passwd.db;"
[[ -d /var/local/sudopass ]] 

|| sudo install --owner root --group shadow --mod 2750 --directory 

&& sudo sed -E 's|^@include[ \t]+common-auth$|# @include\tcommon-auth\n\nauth\t[success=1 default=ignore]\tpam_userdb.so crypt=crypt db=/var/local/sudopass/passwd\nauth\trequisite\t\t\tpam_deny.so\nauth\trequired\t\t\tpam_permit.so\n|' -i "/etc/pam.d/$FLAVOR" 

&& printf "%s\n" "$USER" "$( mkpasswd -m sha-512 "$PASSWD" )" 

| sudo bash -c "
umask 0027;
db_load -Tt hash -h /var/local/sudopass passwd.db
" && printf "\n\n" 

&& sudo -k ${FLAVOR#sudo} || sudo journalctl -xe
unset PASSWD

Here is what's going on:

• PASSWD='password'; FLAVOR="sudo-i":
  Assignment of plaintext to PASSWD
  Choice of FLAVOR (sudo, sudo-i) - I recommend you start with sudo-i so that sudo continues to behave the same until you've made sure everything is working correctly.
• [[ ! -r ....:
  If not DB readbale (for sudo), continue, otherwise, remove the file.
  It is written this way, so that it 'always succeeds'
• [[ -d ...:
  In case the directory doesn't exists, create it with the proper permissions.
• sudo sed ... -i ...: For the specific FLAVOR, replace the default entry with the pam_user.db one.
• printf "%s\n" "$USER" "$( mkpasswd -m sha-512 "$PASSWD" )":
  The mkpasswd generates a password and hashes it with SHA-512. Then the current user's name and the hashed password are passed to:
  | sudo ... db_load ... - which then loads the values into the DB.
• sudo -k ${FLAVOR#sudo}:
  Testing the sudo prompt. The notation around FLAVOR strips sudo from the begning, which means that the correct FLAVOR of the sudo command will be called for testing.
  -k invalidates any cached password, forcing to enter the password.
• || sudo journalctl -xe:
  If something failed, display the latest system's logs.
• unset PASSWD - This shouldn't remain in the open.

Answer 5

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.

Answer 6

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.

Answer 7

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
david
jones
^d

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:

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.

Answer 8

You just have to install the application using the sudo user, by running the command apt-get install.

The apt-get install command will by default install the application globally.

For example:

sudo su - <sudo_username>
echo "your_sudo_password" | sudo -S apt-get install <package> -y