Linux User and Group Management: adduser, sudo, and Access Security

You just booted a Linux server. Logged in as root. Everything works. But now comes the real challenge: how do you manage who has access to what? Leaving everything under root is the fastest way to get your server compromised. We, at Meteora Web, see it every day in projects that come to us: servers with a single root user, weak passwords, no privilege separation. That's why in this guide we go straight to the point: how to create users, assign privileges with sudo, manage groups, and lock down access. No abstract theory: real commands, concrete examples, decisions you can make right now.

Why Separating Users Is the First Security Rule

In a Linux system, every process and every user session has a set of permissions. The root user can do anything. But if an attacker gains a root session, they have full control over the server. Separating access across multiple users limits the damage: if one account is compromised, the harm is contained to that user's permissions. This isn't bureaucracy — it's server survival.

We call it the principle of least privilege: each user should have only the permissions strictly needed to do their job. A user who only needs to upload files via FTP shouldn't have sudo. A developer who needs to restart a service can have a specific sudo rule, not root's full power. On the servers we manage for our clients, we apply this rule from day one.

adduser vs useradd: Which to Use (and Why)

Linux offers two commands to create users: useradd (low-level) and adduser (interactive frontend). For a beginner, adduser is the right choice. It creates the home directory, copies default configuration files, sets the shell, and prompts for a password interactively. useradd, on the other hand, requires you to specify every option manually.

Practical Example: Creating a User with adduser

sudo adduser mario

This command does everything automatically: creates user mario, directory /home/mario, copies files from /etc/skel, sets shell to /bin/bash, and asks for a password. It will also prompt for optional info (full name, phone, etc.) which you can skip by pressing Enter.

If you prefer useradd for more control (useful in scripts), here's the equivalent:

sudo useradd -m -s /bin/bash mario
sudo passwd mario

-m creates the home directory, -s sets the shell. Then set the password separately with passwd.

Groups: Organize Permissions Intelligently

A user can belong to multiple groups. Groups let you manage permissions collectively: instead of giving sudo to ten users one by one, create a sudo group and add users to it. Linux has predefined groups like sudo (or wheel on some distributions) that grant administrative privileges.

Create a Group and Add a User

sudo groupadd developers
sudo usermod -aG developers mario

The -aG option adds the user to the group without removing them from others. Warning: without -a, usermod -G would replace all of the user's groups — a common mistake that could leave you without sudo access if you're not careful.

To verify a user's groups:

groups mario

Or id mario to see numeric IDs as well.

Sudo: Grant the Bare Minimum

The sudo command allows a user to execute commands with another user's privileges (usually root). The configuration file is /etc/sudoers. Never edit it directly with a normal editor: use visudo, which checks syntax before saving.

Grant sudo to a User

To add mario to the sudo group (on Ubuntu/Debian):

sudo usermod -aG sudo mario

On CentOS/RHEL the group is wheel:

sudo usermod -aG wheel mario

After adding, the user must log out and back in (or restart the shell) for the group change to take effect.

Specific Permissions with visudo

If you want a user to run only a specific command, edit /etc/sudoers with visudo:

sudo visudo

Add a line like this:

mario ALL=(ALL) /usr/bin/systemctl restart apache2

Now mario can run only sudo systemctl restart apache2, nothing else via sudo. You can also allow an entire group:

%developers ALL=(ALL) /usr/bin/apt update, /usr/bin/apt upgrade

The % denotes a group.

Access Security: Passwords, SSH, and Keys

A strong password is the minimum. But on a remotely accessible server, SSH keys are far more secure than passwords. Here's what we do on every server we set up:

Disable Root SSH Access

In /etc/ssh/sshd_config set:

PermitRootLogin no

Then restart the service:

sudo systemctl restart sshd

Now nobody can connect as root via SSH. They must first connect as a regular user and then use sudo.

SSH Key Authentication

Generate a key pair on your client machine:

ssh-keygen -t ed25519 -C "comment"

Then copy the public key to the server:

ssh-copy-id mario@server-ip

After verifying key-based login works, disable password authentication in /etc/ssh/sshd_config:

PasswordAuthentication no

Restart sshd.

Cleanly Removing Users and Groups

When a user is no longer needed, don't just delete them. Use deluser (or userdel) with the option to remove home and mail spool.

sudo deluser --remove-home mario

To delete a group:

sudo groupdel developers

Note: you cannot delete a group if it is the primary group of an existing user. Move the user to another group or delete the user first.

Security Best Practices Checklist

Here's a list we apply to every production server for our clients:

No direct root access via SSH (PermitRootLogin no).
SSH key-only authentication (PasswordAuthentication no).
Separate users for each service or person.
Sudo with specific commands where possible, not unlimited sudo.
Disable inactive accounts with usermod --expiredate 1 username to lock access.
Monitor logs with journalctl -u ssh and last to see who logged in.
Use a dedicated sudo group and don't give sudo to everyone.

Summary — What to Do Now

If you have a server with only a root user, stop right here. Create a normal user, give it sudo, and disable root SSH. Then, for every person or service that needs access, create a separate user and assign only the necessary permissions. It's not complicated — it's three commands that stand between you and a disaster.

Immediate actions: