Introduction

The sudo command is one of the tools that every person doing system administration should understand and use.  The basic purpose sudo is to run some command with elevated (root) privilege using a suitably modified set of environment variables.  Before doing this, sudo checks that the user is allowed to run the command, and (if configured to do so) prompts for the user's password.  (More on that later ...)

Configuring sudo


The behaviour of the sudo command is controlled by the "/etc/sudoers" file, and there is a special command ("visudo") for safely editing this file.  This command opens a copy of the "/etc/sudoers" file in your preferred editor (refer to the manual entry) for you to make changes.  When you are finished, you save-and-exit the editor.  The "visudo" program then checks that the new version of the file is syntactically correct, and then atomically updates the original.

But there is a catch!

The problem is that if you make a mistake in editing the "/etc/sudoers" file, it is possible to "lock yourself out".  This is because on NeCTAR virtuals, root login is generally disabled, and the root password is generally unknown.  So if you "stuff up" while changing "/etc/sudoers", you could get into a situation where you can no longer run commands with root privilege.  And of course, that means that "sudo visudo" won't work anymore!

There are a couple of things that you can do two things to mitigate this risk:

  • Before you edit "/etc/password", create yourself a 2nd SSH session to the virtual and start a  root shell by running "sudo bash".  If you somehow manage to "brick" the "/etc/sudoers" file, you can then use the root shell to try to fix the damage.
  • Always use "sudo visudo" rather "sudo vi /etc/sudoers" or similar. The "visudo" command at least does some basic sanity checks.

Note, if you do accidentally lock yourself out, it might be possible to fix the problem.  However, you will need the assistance of a NeCTAR administrator.  Contact your NeCTAR support.

Enabling sudo per user

In NeCTAR Linux virtual images (i.e. the base images that NeCTAR provides) you will typically see a line like the following that grants sudo rights for the administrator account:

ec2-user  ALL=(ALL) NOPASSWD:ALL

This says that the account "ec2-user" has rights to execute all commands as "root", and that no password is required.

To grant equivalent rights to another user (say "fred"), just copy the above line (or equivalent) and change "ec2-user" to "fred".

Enabling sudo by group

The second way to grant / manage sudo rights it by group.  If you look at the "/etc/sudoers" file, you should see some lines that look like this:

## Allows people in group wheel to run all commands
# %wheel  ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

Note that the "#" character is a comment .... so the lines are commented out.  If you remove the "#" on the last of those lines, you will grant full sudo rights (without a password) to all users in the "wheel" group.  (If you are curious about the origin of "wheel", read this.)

Controlling access via group membership has the advantage that you no longer need to edit the "/etc/sudoers" file each time you want to grant or withdraw sudo rights.  Instead you can control a user's sudo rights with the "usermod" command.  For example:

sudo usermod -a -G wheel fred

adds 'fred' to the 'wheel' group.  (Refer to the manual entry for the "usermod" command.)

Why have passwords on sudo?

The traditional way to configure sudo is to have it request the user's password (again) to guard against the possibility that you have left your keyboard unattended.  To prevent this from being too annoying, sudo's password checking is typically configured to not ask for the password if you successfully used "sudo" in the past 5 minutes.

On a typical NeCTAR virtuals, sudo is configured with no password checking on the initial administrator account. There is a pragmatic reason for this, and that is that when you launch a new instance there is no "setup" procedure where you are asked to provide an initial administrator password.  This is not as bad as it sounds, because you can only connect to the administrator account using the SSH public/private key pair that you provided / selected at launch time.  But even so, password gating on sudo is a good thing to have.

Configuring passwords for sudo

First thing you should do is to double-check that the SSH daemon is configures to NOT allow password-based login by running this:

sudo grep PasswordAuthentication /etc/ssh/sshd_conf

You should see a line that looks like this:

PasswordAuthentication no

and not

PasswordAuthentication yes

If you see the latter, then associating a password with a user account potentially makes that account (and hence your entire virtual) vulnerable to password guessing attacks from anywhere on the internet.  That is a bad idea!

Once you have confirmed that it is safe to associate passwords with accounts, then you can simply do this:

  1. Set passwords for each user who needs sudo rights.  See this page for instructions.
  2. Change the user's sudoer's entry from:

    fred  ALL=(ALL)       NOPASSWD: ALL

    to

    fred  ALL=(ALL)       ALL

    or the equivalent if you are using a group.

Note that if you configure a user's sudo entry to require a password and the user's account has no password set, the user will not have sudo access.

Advanced stuff

The sudo command has a lot more functionality that I have not touched on.  For example, you can configure it to allow certain (or all) users to run specific commands which require root access with specific command arguments.  Refer to the manual entry for more details.