4

I have been given a long password by my company for my Ubuntu system. This password is cumbersome to enter when authenticating with sudo repeatedly.

Can I authenticate with sudo using a password other than the one associated with my user account, or enable sudo with no password authentication altogether?

2
  • you should probably rephrase your question to something: 'How to avoid entering p/w with sudo cmd'
    – fduff
    Sep 30, 2014 at 13:36
  • This sounds like an X/Y problem. What is it you're really trying to accomplish?
    – phemmer
    Sep 30, 2014 at 13:37

6 Answers 6

6

You could tie sudo authentication to the knowledge of a secret key managed by ssh-agent. This can be achieved via PAM and the pam_ssh_agent_auth module. You can generate a separate keypair to use exclusively for sudo authentication. The password will be the passphrase used to encrypt the private key.

To configure the pam_ssh_agent_auth module add the following to /etc/pam.d/sudo before any other auth or include directives:

auth       sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys

You will also need to tell sudo not to drop the SSH_AUTH_SOCK environment variable by adding the following to /etc/sudoers (via visudo):

Defaults    env_keep += "SSH_AUTH_SOCK"

Now add the public portion of the key you want to act as the authentication token to /etc/security/authorized_keys. You'd probably also want to add the -t switch to ssh-add with suitable short lifetime when adding the key to have ssh-agent mimic the default sudo behavior of prompting for password confirmation if a certain time has passed since it was last entered, or even use the -c switch to trigger password confirmation each time the key is used for authentication.

Note that the default in Ubuntu is to use GNOME Keyring for SSH key management, which as far as I know doesn't currently allow key timeout to be set. You can disable SSH key management in GNOME Keyring completely by adding the following to ~/.config/autostart/gnome-keyring-ssh.desktop:

[Desktop Entry]
Type=Application
Name=SSH Key Agent
Comment=GNOME Keyring: SSH Agent
Exec=/usr/bin/gnome-keyring-daemon --start --components=ssh
OnlyShowIn=GNOME;Unity;MATE;
X-GNOME-Autostart-Phase=Initialization
X-GNOME-AutoRestart=false
X-GNOME-Autostart-Notify=true
X-GNOME-Autostart-enabled=false
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gnome-keyring
X-GNOME-Bugzilla-Component=general
X-GNOME-Bugzilla-Version=3.10.1
NoDisplay=true
X-Ubuntu-Gettext-Domain=gnome-keyring

which overrides /etc/xdg/autostart/gnome-keyring-ssh.desktop, the key difference being the line:

X-GNOME-Autostart-enabled=false
1

If it is feasible to enable the root account on your Ubuntu system, you can configure sudo to prompt for the root password instead of the password of the invoking user by adding the following to /etc/sudoers (using visudo):

Defaults rootpw

Ubuntu, by default, disables the root account by locking out its password. To enable it simply set a new password for root:

$ sudo passwd root

Even if you want to enable authentication with the root password for sudo, you can keep root logins disabled on local console devices by emptying (or commenting out) everything in /etc/securetty. A blank /etc/securetty file, however, does not prevent the root user from logging in remotely using OpenSSH or other means that are not affected by pam_securetty.so (e.g. su, sudo, ssh, scp, sftp). OpenSSH can be specifically configured to prevent root logins via the PermitRootLogin no stanza in/etc/ssh/sshd_config, but if you decide to do this you should make yourself aware of any other effects that may be relevant in your case.

1

Why don't you just relax having to put the password in, by altering sudo's behavior, like so:

This was taken from the ChromiumOS Tips and Tricks Page: Making Sudo A Little More Permissive

cd /tmp
cat > ./sudo_editor <<EOF
#!/bin/sh
echo Defaults \!tty_tickets > \$1          # Entering your password in one shell affects all shells 
echo Defaults timestamp_timeout=180 >> \$1 # Time between re-requesting your password, in minutes
EOF
chmod +x ./sudo_editor 
sudo EDITOR=./sudo_editor visudo -f /etc/sudoers.d/relax_requirements

If you don't know what was done, tty_tickets is now false, meaning you don't need to authenticate on every tty. Timestamp_timeout is set to every 3 hours, meaning that you input the password once every three hours. Between the time you put it in, and the three hour limit, typing sudo some command will not result in being asked for your password until the limit expires.

relax_requirement can now be used to control sudo. Available Options are in the Sudoer's Manual. Look for the bolded section SUDOERS OPTIONS. There are plenty of options besides the ones I described. Doing it this way requires no modifications to PAM etc, and works on any system with or without PAM.

1

pam_ssh_agent_auth is overkill. It requires an agent.

This presumes sudo is already configured, and that configuration is not with NOPASSWD; you want a check, but a different check than login, be it randomized password or ssh key.

HOW TO SET UP YOU OWN PASSWORD LIST FOR SUDO (on debian 12)

sudo apt install libpam-pwdfile

nano /etc/pam.d/sudo

%PAM-1.0
auth required pam_pwdfile.so pwdfile=/etc/security/sudo_passwd
#@include common-auth
@include common-account
@include common-session-noninteractive

nano /etc/security/sudo_passwd

yourusername:

openssl passwd -6 >> /etc/security/sudo_passwd

nano /etc/security/sudo_passwd

To see your shiny encrypted password after your user name - there should be no spaces in it!

Repeat as needed

Test sudo on a clean terminal - your password should work, but don't exit until you are sure it does.

0

You can edit the file /etc/sudoers with your editor of choice or just execute visudo and add the line to allow your specific user to use the sudo command without password. Something like:

user ALL = NOPASSWD : ALL

4
  • Even better, but why not just a cron script to keep UIDs and GUIDs in sync between two users? Sep 30, 2014 at 13:50
  • 6
    @Isaac You should never edit /etc/sudoers without using visudo. visudo takes a number of precautions to avoid leaving the sudoers file in an inconsistent state, including locking the file against multiple simultaneous edits, providing basic sanity checks, and checking the file for parse errors before it is written to disk. Corrupting the sudoers file can potentially leave you stranded without administrator access, especially on Ubuntu where root logins are disabled by default. visudo honors the EDITOR environment variable if you want to use an editor other than Vi(m). Sep 30, 2014 at 14:47
  • Also, /etc/sudoers is the global settings file. User A does this to make it easier, but if User B can also sudo, this works for User B. That may not be the intended behavior.
    – eyoung100
    Sep 30, 2014 at 17:20
  • -1 for not knowing Thomas's comment.
    – eyoung100
    Sep 30, 2014 at 17:22
0

Keep an shell open, where you have used sudo -i, the interactive mode. Everytime you need to do something as root, do it inside this shell.

Then you could also re-run more then once needed commands by searching them via [STRG] + R, f.e. updating:

aptitude update && aptitude upgrade && aptitude dist-upgrade

If its reasonable or practical for your purposes, you could use a tty for this. Then it's easy to find, if you have a lot of programs running in *DM.

You must log in to answer this question.

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