Stackvora.tech

Add a Sudo User on Ubuntu/Debian

Secure and efficient user management is fundamental to robust system administration. On Ubuntu and Debian systems, creating non-root users with…

Secure and efficient user management is fundamental to robust system administration. On Ubuntu and Debian systems, creating non-root users with administrative privileges via sudo is a standard practice for enhancing security and accountability. This guide details the process, including essential security considerations like SSH key authentication and judicious use of passwordless sudo.

This article focuses on Ubuntu 20.04 LTS (Focal Fossa) and Debian 11 (Bullseye), though the commands and concepts are broadly applicable to other recent versions of these distributions.

Creating a New User Account

The primary tool for adding users on Debian-family systems is adduser. Unlike useradd, adduser is a Perl script that provides a more interactive and user-friendly experience, automatically handling tasks like home directory creation, shell assignment, and copying default configuration files.

sudo adduser alice

Upon execution, adduser will prompt you for:

  • A new UNIX password for alice (and a re-confirmation). Choose a strong, unique password.
  • Optional full name (GECOS field).
  • Optional room number, work phone, home phone, and other information. You can usually press Enter to skip these.
  • A final confirmation for the information entered.

By default, adduser creates:

  • A home directory at /home/alice.
  • A primary group named alice (matching the username).
  • Assigns /bin/bash as the default shell.

Granting Sudo Privileges

To allow alice to execute commands with superuser privileges, you need to add them to the sudo group. Members of this group are typically configured in /etc/sudoers (or files within /etc/sudoers.d/) to use sudo.

sudo usermod -aG sudo alice
  • usermod: Utility to modify user account properties.
  • -a: Append the user to the supplementary group(s) specified. This is crucial; without it, -G would remove the user from all other supplementary groups.
  • -G sudo: Specifies the sudo group as the target for appending.
  • alice: The username to modify.

This command modifies the /etc/group file and assigns the user alice to the sudo group. No service restart is required, but the user must log out and log back in for the new group membership to take effect.

Verification

After adding the user to the sudo group, switch to the new user and verify their privileges. This should be done from a fresh terminal session or by using su - alice:

su - alice
sudo -v

The sudo -v command (v for validate) will prompt for alice's password. If successful, it will renew the user's sudo timestamp for 5 minutes (default) and return an exit code of 0 without any output. If the user does not have sudo privileges, it will typically show an error like "alice is not in the sudoers file. This incident will be reported."

Configuring SSH Key-Based Authentication

Using SSH keys for authentication is vastly more secure than passwords, especially for administrative accounts. This section details how to set up key-based authentication for alice.

Generating an SSH Key Pair (Local Machine)

On your local machine (e.g., laptop), generate an SSH key pair if you haven't already:

ssh-keygen -t ed25519 -C "alice@production-server-01"
  • -t ed25519: Specifies the Ed25519 algorithm, which is generally preferred over RSA for its strong security and smaller key sizes.
  • -C "comment": Adds a comment to the public key, useful for identifying the key's purpose or owner.

This will typically create two files in ~/.ssh/: id_ed25519 (private key) and id_ed25519.pub (public key).

Deploying the Public Key to the Server

Now, deploy alice's public key to the server. You can do this securely from your local machine using ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub alice@your_server_ip

This command will prompt for alice's password on the server and then automatically perform the following steps:

  1. Create the /home/alice/.ssh directory if it doesn't exist.
  2. Set appropriate permissions (chmod 700) for /home/alice/.ssh.
  3. Append the public key from ~/.ssh/id_ed25519.pub to /home/alice/.ssh/authorized_keys.
  4. Set appropriate permissions (chmod 600) for /home/alice/.ssh/authorized_keys.
  5. Set ownership (chown alice:alice) for /home/alice/.ssh and its contents.

If ssh-copy-id is not available or you prefer a manual approach, you can do it from the server as root (or an existing sudo user):

# As root or an existing sudo user
sudo mkdir -p /home/alice/.ssh
sudo chmod 700 /home/alice/.ssh
# Replace AAAA... with alice's actual public key string
echo "ssh-ed25519 AAAA... alice@laptop" | sudo tee /home/alice/.ssh/authorized_keys
sudo chmod 600 /home/alice/.ssh/authorized_keys
sudo chown -R alice:alice /home/alice/.ssh

After deploying the key, test the connection:

ssh alice@your_server_ip

You should now be able to log in without a password. If prompted for a password, check permissions and the contents of authorized_keys.

Securing SSH Daemon Configuration

Once SSH key authentication is confirmed working, it's highly recommended to disable password-based SSH logins and root login directly via SSH.

sudo nano /etc/ssh/sshd_config

Locate and modify or add the following lines:

# Disable password authentication
PasswordAuthentication no

# Permit only public key authentication
PubkeyAuthentication yes

# Disallow root login directly via SSH
PermitRootLogin no

# Allow SSH for specific users/groups (optional but recommended for tight control)
# AllowUsers alice bob
# AllowGroups sshusers # if you create an 'sshusers' group and add users to it

After making changes, reload the SSH daemon to apply them:

sudo systemctl reload sshd # Debian/Ubuntu 18.04+
# or for older systems:
# sudo service ssh reload

Crucial Note: Before reloading sshd, ensure you have a separate, active SSH session open as alice (or another sudo user with key access) to verify connectivity. If you lock yourself out, you may need console access to regain control.

Optional: Passwordless Sudo for Automation

For service accounts, CI/CD pipelines, or specific automation tasks, passwordless sudo might be necessary. This should be used with extreme caution and only for specific, non-human users or highly controlled scripts, as it removes a critical layer of security.

sudo visudo -f /etc/sudoers.d/alice_nopass

The -f flag tells visudo to edit a specific file. Using /etc/sudoers.d/ is preferred over directly editing /etc/sudoers, as it keeps configurations modular and easier to manage, especially during upgrades. Create a new file (e.g., alice_nopass) and add the following line:

alice ALL=(ALL) NOPASSWD:ALL
  • alice: The username.
  • ALL=(ALL): Specifies that the user can run commands as any user (first ALL) and any group (second ALL).
  • NOPASSWD:ALL: Allows the user to run any command (ALL) without a password prompt.

Save and exit visudo (usually Ctrl+X, Y, Enter if using nano as default editor). visudo will check the syntax before saving, preventing errors that could lock out sudo functionality.

To restrict passwordless sudo to specific commands (a more secure approach):

alice ALL=(ALL) NOPASSWD: /usr/bin/apt update, /usr/bin/apt upgrade

Always specify the full path to commands to prevent exploits via PATH manipulation.

Removing a User

When an account is no longer needed, it should be removed to reduce the attack surface.

sudo deluser --remove-home alice
  • deluser: The Debian/Ubuntu utility for removing users.
  • --remove-home: Deletes the user's home directory and mail spool. Without this, only the user account is removed, leaving files behind.

If the user also had an entry in /etc/sudoers.d/, remember to manually remove that file as well:

sudo rm /etc/sudoers.d/alice_nopass

Common Pitfalls

  • Incorrect Permissions on .ssh or authorized_keys: SSH requires strict permissions. .ssh must be 700 (rwx------) and authorized_keys must be 600 (rw-------). Incorrect ownership or group permissions (e.g., owned by root) will prevent key authentication. Always ensure the user owns their own .ssh directory and its contents.
  • Forgetting -a with usermod -G: Using usermod -G sudo alice (without -a) will remove alice from all other groups, which can break functionality or even SSH access if the user was part of an sshusers group. Always use -aG to append to existing groups.
  • Editing /etc/sudoers directly without visudo: Editing /etc/sudoers with a standard text editor is dangerous. A syntax error can render sudo unusable, potentially locking out all administrative users. Always use visudo, which performs syntax checks.
  • Disabling password authentication before verifying SSH key access: Ensure you can log in with your SSH key *before* setting PasswordAuthentication no in sshd_config. Keep at least one root or sudo session open while testing.
  • Using passwordless sudo for human users: This practice severely compromises security. Reserve NOPASSWD for specific, auditable automation accounts with highly restricted command sets.
  • SSH agent forwarding issues: If you're using SSH agent forwarding, ensure your local agent is running and has your private key loaded (ssh-add ~/.ssh/id_ed25519).

Back to the knowledge base · Ask the AI assistant