Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
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). –  Jiri Xichtkniha Oct 11 '13 at 13:33

5 Answers 5

up vote 12 down vote accepted

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
share|improve this answer
    
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? –  Shâu Shắc 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? –  Shâu Shắc Oct 15 '13 at 5:01
    
@ShâuShắc I believe RHEL, Fedora, and CentOS call it libdb-utils. The command name may be a little different, too (maybe it won't have a version, or will be a different version—but it'll match db.*_load) –  derobert Oct 15 '13 at 5:22

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.

share|improve this answer
1  
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

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?

share|improve this answer
    
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

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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