Linux is designed for multiple users. Even on a single server, different services, admins, and automation systems may run under different accounts. Good account management improves security, auditing, and operational safety.
Instead of giving every process full root access, Linux encourages controlled access through users, groups, and privilege escalation tools.
Start with the commands that tell you who you are.
whoami
idwhoami prints your current username. id shows your numeric user ID, primary group, and supplementary groups.
Example output:
uid=1001(devops) gid=1001(devops) groups=1001(devops),27(sudo),998(docker)This tells you not only the user name, but also what groups affect your permissions.
Use useradd to create a user account.
sudo useradd -m -s /bin/bash deployCommon options:
-m creates the home directory-s sets the login shellSet a password with:
sudo passwd deployRemove a user with:
sudo userdel deploy
sudo userdel -r deploy-r also removes the home directory.
Tip: Be careful with
userdel -rbecause it removes the userâs home data too.
usermodusermod updates existing accounts.
sudo usermod -aG docker deploy
sudo usermod -s /bin/zsh deployThe -aG combination appends the user to supplementary groups. This is important: using -G without -a can replace existing group memberships.
Groups make permission management easier.
Create a group:
sudo groupadd developersAdd a user to it:
sudo usermod -aG developers deployGroups are useful when multiple users need access to the same application directories, logs, or deployment scripts.
sudo vs susudosudo runs a command with elevated privileges, typically as root.
sudo systemctl restart nginx
sudo cat /etc/shadowIt is preferred because it gives controlled, auditable elevation for specific commands.
susu switches to another user account.
su - deploy
sudo su -su - starts a full login shell for the target user.
In modern administration, sudo is usually favored over sharing the root password.
/etc/passwd/etc/passwd stores basic account information such as username, UID, GID, home directory, and login shell.
cat /etc/passwdA sample entry looks like this:
deploy:x:1002:1002:Deployment User:/home/deploy:/bin/bash/etc/shadow/etc/shadow stores password hashes and password policy information.
sudo cat /etc/shadowThis file is restricted because password hashes are sensitive.
Note:
/etc/passwdis readable by normal users on many systems, but/etc/shadowshould be protected.
Sudo permissions are often configured through /etc/sudoers or files in /etc/sudoers.d/.
Always edit sudo rules with:
sudo visudovisudo checks syntax before saving. That matters because a broken sudoers file can lock administrators out of privileged access.
A common pattern is group-based sudo access, such as allowing members of a sudo or wheel group to elevate privileges.
A CI user needs to run Docker commands without typing sudo each time.
sudo usermod -aG docker ci-runnerThe user may need to log out and back in before the new group membership applies.
You might create a dedicated account that owns application files and runs deployment scripts.
sudo useradd -m -s /bin/bash deploy
sudo passwd deploy
sudo usermod -aG developers deployThis keeps deployment activity separate from personal admin accounts.
sudo over sharing root credentials/etc/passwd, /etc/shadow, and sudo rules carefullyQuestion: Why is usermod -aG docker deploy safer than using -G docker without -a?
<MCQExercise exercise={{
id: 'linux-users-groups-q1',
title: 'Exercise 1: Preserving existing groups',
description: 'Choose why the append flag matters when modifying supplementary group membership.',
options: [
{ id: 'a', text: 'Because -aG appends the docker group instead of replacing the user\'s other supplementary groups.' },
{ id: 'b', text: 'Because -aG automatically sets the user\'s password hash in /etc/shadow.' },
{ id: 'c', text: 'Because -aG deletes the home directory after the change.' },
{ id: 'd', text: 'Because -aG grants full root access without sudo rules.' },
],
correctId: 'a',
explanation: 'The lesson warns that using -G alone can replace existing supplementary groups. Adding -a appends the new group membership instead, which avoids accidentally stripping other access the user already has.',
wrongExplanations: {
b: 'Password hashes are handled by passwd and stored in /etc/shadow, not by group appending flags.',
c: 'Group modification does not remove the user\'s home directory.',
d: 'Being in a group such as docker is not the same as automatically receiving unrestricted root access.',
},
}} />
Question: Which file from the lesson stores password hashes and therefore needs tighter protection?
<MCQExercise exercise={{
id: 'linux-users-groups-q2',
title: 'Exercise 2: Distinguishing passwd and shadow',
description: 'Identify which account file contains password hashes.',
options: [
{ id: 'a', text: '/etc/passwd' },
{ id: 'b', text: '/etc/group' },
{ id: 'c', text: '/etc/shadow' },
{ id: 'd', text: '/etc/profile' },
],
correctId: 'c',
explanation: 'The tutorial explains that /etc/shadow stores password hashes and password policy data, which is why normal users should not have broad access to it. By contrast, /etc/passwd holds general account metadata.',
wrongExplanations: {
a: '/etc/passwd contains usernames, UIDs, home directories, and shells, but modern systems keep password hashes elsewhere.',
b: '/etc/group describes groups and group membership, not password hashes.',
d: '/etc/profile is related to shell environment setup rather than account credential storage.',
},
}} />
Question: What is the key reason to use visudo when changing sudo rules?
<MCQExercise exercise={{
id: 'linux-users-groups-q3',
title: 'Exercise 3: Avoiding broken sudoers files',
description: 'Choose why visudo is the recommended editor for sudo configuration.',
options: [
{ id: 'a', text: 'It automatically adds every user to the sudo group.' },
{ id: 'b', text: 'It verifies sudoers syntax before saving so you do not lock yourself out.' },
{ id: 'c', text: 'It encrypts the entire /etc directory.' },
{ id: 'd', text: 'It replaces both sudo and su with a graphical wizard.' },
],
correctId: 'b',
explanation: 'The lesson emphasizes that visudo performs a syntax check before saving changes. That validation matters because a malformed sudoers file can break privileged access for administrators.',
wrongExplanations: {
a: 'visudo edits policy, but it does not automatically grant sudo access to everyone.',
c: 'It has nothing to do with encrypting /etc. Its purpose is safe editing and validation of sudo rules.',
d: 'visudo is not a replacement for sudo or su. It is specifically an editor workflow for sudo configuration.',
},
}} />
useradd is low-level, adduser is the friendly wrapper on Debian and Ubuntu.usermod -aG appears not to work.-aG, never -G alone. Without -a, you replace every secondary group the user had.sudo runs one command with logging; su becomes another user for the rest of the session.sudo -i to su -, because it is logged and does not need the root password./etc/passwd is world-readable; /etc/shadow is not: hashes live in shadow for that reason.visudo, never a plain editor, on sudoers files: it validates syntax before saving.Group membership is attached to your session at login and is not re-read afterwards, so a shell that was already open keeps the group list it started with no matter what you change. Log out and back in, or run newgrp <group> to start a shell with the new membership immediately. For a systemd service, restart the service rather than the session. This is the single most common "the command worked but nothing changed" moment in Linux administration.
-aG appends the listed groups to the user's existing secondary groups. -G replaces them entirely, so usermod -G docker alice removes Alice from every other secondary group she was in, including sudo, which can lock an administrator out of their own machine. The -a is only meaningful with -G, and omitting it is a genuinely destructive mistake. Check the result with groups alice or id alice immediately afterwards.
sudo runs a single command as another user, defaulting to root, authenticating with your own password and logging what was run. su switches to another user for an entire session and needs that user's password. sudo is preferable for administration: nobody needs to know the root password, permissions can be granted per command in sudoers, and every invocation is recorded in the auth log. Where you genuinely want a root shell, sudo -i gives one with the same audit trail.
/etc/passwd holds account records, username, UID, GID, home directory, shell, and is world-readable, because ordinary programs need to map UIDs to names. Password hashes were historically in that file, which meant anyone could copy them and attack offline, so they moved to /etc/shadow, readable only by root, along with expiry and ageing fields. /etc/group lists groups and their secondary members. Edit them with usermod, chage and gpasswd rather than by hand.
Add them to the administrative group: usermod -aG sudo alice on Debian and Ubuntu, or wheel on RHEL-family systems. They must log out and back in for it to apply. For narrower access, add a file under /etc/sudoers.d/ granting specific commands, alice ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, which is better practice than full root for a service operator. Always edit sudoers files with visudo (or visudo -f), since it validates the syntax and a malformed sudoers file locks everyone out.
Manage Linux services with systemctl: start versus enable, daemon-reload after edits, writing a unit file, what Type= controls and reading logs.
Diagnose Linux networking with ip and ss instead of ifconfig and netstat, learn why ping proves little, debug DNS with dig and choose rsync over scp.
Find and fix Linux disk problems: why df and du disagree, deleted-but-open files, inode exhaustion, persistent mounts by UUID in fstab and tar versus zip.