Linux user management: useradd, passwd, su, giving and taking sudo with wheel, and userdel

By Ravindra Bagale, trainer · LinkedIn · Last updated: 8 October 2026

1. Where we are

Why this chapter. In Linux users, groups, sudo and file permissions you made ravi with sudo adduser, saw that he gets a group with the same name, and logged in as him with an SSH key. In chmod in depth you saw that ec2-user can use sudo and ravi can't. This chapter goes through the full life of a user, step by step, as an admin does it on a real server.

The story. ec2-user is the server owner. The team lead keeps that login. Developers get normal users like ravi and ramesh, with no sudo at first.

All commands in this chapter were run on a test copy of Amazon Linux 2023 with the same sudo, login.defs and PAM settings as an EC2 server. Your hostname, dates and process numbers will differ.

2. Why a normal user can't just use sudo

Why. In class a student asked the obvious question:

What. Exactly. sudo means "do this as root", and root can do anything. If every user could use it, separate users would protect nothing. So on Amazon Linux:

1. ec2-user can use sudo from the start.
2. A new user like ravi can't, until an admin allows it.
3. Each user works in their own home, and the others can't look inside.

How it looks. As ravi, try to make a file with sudo. The first time, sudo shows a short lecture, asks for ravi's own password, and then refuses:

[ravi@ip-172-31-xx-xx ~]$ sudo touch sudotest.txt

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

For security reasons, the password you type will not be visible.

[sudo] password for ravi:
ravi is not in the sudoers file.

Notice the message: it is not "Permission denied". It says ravi has no sudo rule at all. The lecture appears only the first time each user runs sudo.

3. What a normal user can and can't do

Why. You need to know where the walls are before you start giving rights away.

What. / and /home are open for everyone to enter and list (r-x). Homes are 700, so only the owner gets in. /etc/passwd is readable by all; /etc/shadow is not.

Example 1: looking around works. Run these as ravi:

[ravi@ip-172-31-xx-xx ~]$ cd /
[ravi@ip-172-31-xx-xx /]$ ls
bin  boot  dev  etc  home  lib  lib64  local  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[ravi@ip-172-31-xx-xx /]$ ls -ld /home /home/ec2-user /home/ravi
drwxr-xr-x. 4 root     root      35 Jan  5 10:15 /home
drwx------. 2 ec2-user ec2-user  62 Jan  5 10:15 /home/ec2-user
drwx------. 2 ravi     ravi      62 Jan  5 10:15 /home/ravi

Example 2: the walls. Still as ravi:

[ravi@ip-172-31-xx-xx ~]$ ls /home/ec2-user
ls: cannot open directory '/home/ec2-user': Permission denied
[ravi@ip-172-31-xx-xx ~]$ cat /etc/shadow
cat: /etc/shadow: Permission denied
[ravi@ip-172-31-xx-xx ~]$ useradd test1
useradd: Permission denied.
useradd: cannot lock /etc/passwd; try again later.

4. Step 1: create the user with useradd

Why. A user is more than a folder. Linux needs an entry in /etc/passwd, a group, a home and a password entry. useradd makes all of them in one go. Never "create a user" by making a folder in /home.

What. On Amazon Linux 2023, useradd and adduser are the same program. One command creates:

1. The user ravi, with the next free number (UID), here 1001.
2. A group ravi with the same number.
3. The home /home/ravi, with mode 700.
4. A mailbox file /var/spool/mail/ravi.
5. A locked password entry (!!), so nobody can log in with a password yet.

Example 3: create and check. As ec2-user:

[ec2-user@ip-172-31-xx-xx ~]$ sudo useradd ravi
[ec2-user@ip-172-31-xx-xx ~]$ id ravi
uid=1001(ravi) gid=1001(ravi) groups=1001(ravi)
[ec2-user@ip-172-31-xx-xx ~]$ grep ravi /etc/passwd
ravi:x:1001:1001::/home/ravi:/bin/bash
[ec2-user@ip-172-31-xx-xx ~]$ sudo grep ravi /etc/shadow | cut -d: -f1,2
ravi:!!

useradd prints nothing when it works. Silence means success.

5. Step 2: set the password with passwd

Why. A new user's password is locked. Until you set one, su ravi can't work:

[ec2-user@ip-172-31-xx-xx ~]$ su ravi
Password:
su: Authentication failure

How. Set it as the admin, with sudo:

[ec2-user@ip-172-31-xx-xx ~]$ sudo passwd ravi
Changing password for user ravi.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

While you type, nothing appears: no stars, and the cursor doesn't move. That's on purpose, so nobody looking at your screen can count the letters.

Example 4: weak passwords. Linux checks the new password and warns you. Here are the real messages:

BAD PASSWORD: The password is shorter than 8 characters
BAD PASSWORD: The password contains the user name in some form
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word

When root (you, with sudo) sets the password, this is only a warning: retype it and it is saved. When ravi changes his own password with plain passwd, the same checks are enforced. After three weak tries he gets:

passwd: Have exhausted maximum number of retries for service

If the two entries don't match, you see Sorry, passwords do not match. and get asked again.

Example 5: someone forgot their password. The admin resets it. The old password isn't needed:

sudo passwd ravi

Example 6: what ravi may do with passwd. ravi can change only his own password, and must type the current one first. He can't touch anyone else's:

[ravi@ip-172-31-xx-xx ~]$ passwd ramesh
passwd: Only root can specify a user name.

su passwd ravi
su: user passwd does not exist or the user entry does not contain all the required fields

6. Step 3: switch users with su and su -

Why. In class we play several people on one server, so we switch users inside it. On a real team, everyone logs in directly with their own key (ssh -i key.pem ravi@SERVER_PUBLIC_IP, after their public key is in /home/ravi/.ssh/authorized_keys, as shown in the users chapter). su is the classroom shortcut.

What. su = "switch user". It asks for the password of the user you switch to.

1. su ravi: you become ravi, but you stay in the folder you were in.
2. su - ravi: a full login as ravi. You land in /home/ravi with a fresh environment.

Example 7: su ravi keeps you in the old folder.

[ec2-user@ip-172-31-xx-xx ~]$ su ravi
Password:
[ravi@ip-172-31-xx-xx ec2-user]$ pwd
/home/ec2-user
[ravi@ip-172-31-xx-xx ec2-user]$ ls
ls: cannot open directory '.': Permission denied
[ravi@ip-172-31-xx-xx ec2-user]$ cd
[ravi@ip-172-31-xx-xx ~]$ pwd
/home/ravi
[ravi@ip-172-31-xx-xx ~]$ touch a.txt
[ravi@ip-172-31-xx-xx ~]$ mkdir myfolder

Read the prompt: ravi is the user, ip-172-31-xx-xx the server, ec2-user the folder you're in, and $ means a normal user (# would mean root). ls failed because /home/ec2-user is 700 and belongs to ec2-user. A plain cd takes ravi home, where he can work.

Example 8: su - ravi gives a full login.

[ec2-user@ip-172-31-xx-xx ~]$ su - ravi
Password:
Last login: Mon Jan  5 10:15:37 UTC 2026 on pts/1
[ravi@ip-172-31-xx-xx ~]$ pwd
/home/ravi

Example 9: going back. Type exit, or press Ctrl+D. Both end ravi's shell and you are ec2-user again:

[ravi@ip-172-31-xx-xx ~]$ exit
logout
[ec2-user@ip-172-31-xx-xx ~]$ whoami
ec2-user

After su ravi (without the dash) the word printed is exit instead of logout. Same result.

[ravi@ip-172-31-xx-xx ~]$ sleep 30
^C
[ravi@ip-172-31-xx-xx ~]$ whoami
ravi

7. Users are isolated: add ramesh

Why. Each person's files are private by default. Let's prove it with a second user.

Example 10: second user, next UID.

[ec2-user@ip-172-31-xx-xx ~]$ sudo useradd ramesh
[ec2-user@ip-172-31-xx-xx ~]$ sudo passwd ramesh
[ec2-user@ip-172-31-xx-xx ~]$ tail -3 /etc/passwd
ec2-user:x:1000:1000:EC2 Default User:/home/ec2-user:/bin/bash
ravi:x:1001:1001::/home/ravi:/bin/bash
ramesh:x:1002:1002::/home/ramesh:/bin/bash

Example 11: ramesh can't look into ravi's home.

[ec2-user@ip-172-31-xx-xx ~]$ su - ramesh
Password:
[ramesh@ip-172-31-xx-xx ~]$ cd /home/ravi
-bash: cd: /home/ravi: Permission denied
[ramesh@ip-172-31-xx-xx ~]$ ls /home/ravi
ls: cannot open directory '/home/ravi': Permission denied
[ramesh@ip-172-31-xx-xx ~]$ exit

8. Reading /etc/passwd

Why. Every user you made is one line in /etc/passwd. Reading it tells you the user's number, main group, home and shell.

What. The line has seven fields separated by :

ravi:x:1001:1001::/home/ravi:/bin/bash

1. ravi: the user name.
2. x: the password is not here; it is kept, as a hash, in /etc/shadow.
3. 1001: the UID, the user's number. Linux really works with this number.
4. 1001: the GID, the number of the main group (ravi).
5. (empty): a comment, like a full name. ec2-user's says EC2 Default User.
6. /home/ravi: the home folder.
7. /bin/bash: the shell started at login.

UIDs on Amazon Linux 2023. root is 0. Accounts for system services are below 1000. ec2-user is 1000, and each new user gets the next number: ravi 1001, ramesh 1002.

Example 12: just read it, no sudo needed.

[ec2-user@ip-172-31-xx-xx ~]$ ls -l /etc/passwd /etc/shadow
-rw-r--r--. 1 root root 1836 Jan  5 10:15 /etc/passwd
----------. 1 root root  998 Jan  5 10:15 /etc/shadow
[ec2-user@ip-172-31-xx-xx ~]$ grep ramesh /etc/passwd
ramesh:x:1002:1002::/home/ramesh:/bin/bash

/etc/passwd is readable by everyone. /etc/shadow has no permission bits at all, so only root can read it.

9. Where ec2-user's sudo comes from

Why. Before giving sudo to ravi, look at how ec2-user got it.

What. Two rules on an Amazon Linux 2023 server can give sudo:

1. In /etc/sudoers: %wheel ALL=(ALL) ALL. Every member of the group wheel may run anything as root, after typing their own password.
2. In /etc/sudoers.d/90-cloud-init-users, written by cloud-init at first boot: ec2-user ALL=(ALL) NOPASSWD:ALL. ec2-user may run anything with no password.

Example 13: see both rules. As ec2-user:

[ec2-user@ip-172-31-xx-xx ~]$ id
uid=1000(ec2-user) gid=1000(ec2-user) groups=1000(ec2-user),4(adm),10(wheel),190(systemd-journal)
[ec2-user@ip-172-31-xx-xx ~]$ sudo -l
...
User ec2-user may run the following commands on ip-172-31-xx-xx:
    (ALL) ALL
    (ALL) NOPASSWD: ALL
[ec2-user@ip-172-31-xx-xx ~]$ sudo passwd -S ec2-user
ec2-user LK 2026-01-05 0 99999 7 -1 (Password locked.)

ec2-user is in wheel, but its password is locked (you log in with a key). So the wheel rule alone would ask for a password it doesn't have. The NOPASSWD rule from cloud-init is what lets ec2-user run sudo without being asked. We tested both on the box:

1. ec2-user taken out of wheel, cloud-init rule kept: sudo whoami still prints root.
2. ec2-user in wheel, cloud-init rule removed: sudo asks for a password, and after three tries says sudo: 3 incorrect password attempts.

Check any user without becoming them:

[ec2-user@ip-172-31-xx-xx ~]$ sudo -l -U ravi
User ravi is not allowed to run sudo on ip-172-31-xx-xx.

10. Step 4: give sudo by adding to wheel

Why. Sometimes a developer really needs root work, like installing a package with sudo yum install -y tree or restarting a service with sudo service nginx restart. Instead of sharing ec2-user, add that person to wheel.

How. Any user who already has sudo can do it. As ec2-user:

[ec2-user@ip-172-31-xx-xx ~]$ sudo usermod -aG wheel ravi
[ec2-user@ip-172-31-xx-xx ~]$ groups ravi
ravi : ravi wheel
[ec2-user@ip-172-31-xx-xx ~]$ sudo -l -U ravi
...
User ravi may run the following commands on ip-172-31-xx-xx:
    (ALL) ALL

1. usermod: change an existing user.
2. -G wheel: the extra group to set.
3. -a: append, keep the groups ravi already has. Without -a, -G replaces his extra groups with only the ones you list.

Example 14: ravi uses sudo in a new login. He types his own password, not root's and not ec2-user's:

[ec2-user@ip-172-31-xx-xx ~]$ su - ravi
Password:
[ravi@ip-172-31-xx-xx ~]$ id
uid=1001(ravi) gid=1001(ravi) groups=1001(ravi),10(wheel)
[ravi@ip-172-31-xx-xx ~]$ sudo touch /home/suudowala.txt
[sudo] password for ravi:
[ravi@ip-172-31-xx-xx ~]$ ls -l /home/suudowala.txt
-rw-r--r--. 1 root root 0 Jan  5 10:15 /home/suudowala.txt

The file belongs to root, because sudo ran touch as root. For about five minutes after a correct password, sudo doesn't ask again in that terminal.

Example 15: a shell opened before the change doesn't get it. If ravi was already logged in when you ran usermod, that old shell still fails:

[ravi@ip-172-31-xx-xx ~]$ id
uid=1001(ravi) gid=1001(ravi) groups=1001(ravi)
[ravi@ip-172-31-xx-xx ~]$ sudo whoami
[sudo] password for ravi:
ravi is not in the sudoers file.

He has to exit and log in again. Section 12 explains why.

11. Step 5: take sudo away with gpasswd -d

How. As ec2-user, remove ravi from wheel:

[ec2-user@ip-172-31-xx-xx ~]$ sudo gpasswd -d ravi wheel
Removing user ravi from group wheel
[ec2-user@ip-172-31-xx-xx ~]$ groups ravi
ravi : ravi

gpasswd -d = delete this user from this group. His other groups stay as they are.

Example 16: the surprise. In the shell ravi opened while he was still in wheel, sudo keeps working:

[ravi@ip-172-31-xx-xx ~]$ id
uid=1001(ravi) gid=1001(ravi) groups=1001(ravi),10(wheel)
[ravi@ip-172-31-xx-xx ~]$ sudo whoami
root

Example 17: a fresh login loses it.

[ravi@ip-172-31-xx-xx ~]$ exit
logout
[ec2-user@ip-172-31-xx-xx ~]$ su - ravi
Password:
[ravi@ip-172-31-xx-xx ~]$ sudo whoami
[sudo] password for ravi:
ravi is not in the sudoers file.

12. Why sudo kept working: groups are fixed at login

Why. It looks like a bug, but it's how Linux works, and you need to know it when you take rights away from someone.

What. When you log in, your shell gets a list of groups from /etc/group, and keeps that list until it ends. id with no name shows the list of your current shell. groups ravi and id ravi read the files on disk. sudo checks the groups of the shell that runs it.

Two explanations were possible, so we tested both on the box:

1. The sudo password cache. After a correct password, sudo doesn't ask again for about five minutes. In the old shell we cleared it with sudo -k and ran sudo whoami again. It asked for ravi's password and still printed root. So the cache is not the reason; it only skips the password question.
2. The shell's own group list. The old shell's id still showed 10(wheel) after gpasswd -d. A fresh su - ravi showed only 1001(ravi), and sudo failed there. This is the real reason.

It works the same way when you add a group: the shell from Example 15 didn't get wheel until a new login.

13. Step 6: delete the user with userdel

Why. When someone leaves the team, remove their login. The question is what happens to their files.

What. Two ways:

1. sudo userdel ravi: removes the user, but keeps /home/ravi and his mailbox /var/spool/mail/ravi.
2. sudo userdel -r ravi: removes the user and his home and mailbox.

Example 18: ravi is still logged in. userdel refuses while the user has running processes:

[ec2-user@ip-172-31-xx-xx ~]$ sudo userdel ravi
userdel: user ravi is currently used by process 2412

Ask him to log out (or end his sessions, as in the tip above), then try again.

Example 19: plain userdel keeps the home.

[ec2-user@ip-172-31-xx-xx ~]$ sudo userdel ravi
[ec2-user@ip-172-31-xx-xx ~]$ su ravi
su: user ravi does not exist or the user entry does not contain all the required fields
[ec2-user@ip-172-31-xx-xx ~]$ ls -l /home
total 0
drwx------. 2 ec2-user ec2-user 62 Jan  5 10:15 ec2-user
drwx------. 2 ramesh   ramesh   62 Jan  5 10:15 ramesh
drwx------. 3     1001     1001 78 Jan  5 10:15 ravi
-rw-r--r--. 1 root     root      0 Jan  5 10:15 suudowala.txt

The folder is still there, and the owner now shows as the bare number 1001, because no user has that number any more.

Example 20: -r must be used instead of userdel, not after it. Once the user is gone, -r has nothing to work with:

[ec2-user@ip-172-31-xx-xx ~]$ sudo userdel -r ravi
userdel: user 'ravi' does not exist

Example 21: the right way, in one step.

[ec2-user@ip-172-31-xx-xx ~]$ sudo userdel -r ramesh
[ec2-user@ip-172-31-xx-xx ~]$ ls /home
ec2-user  ravi  suudowala.txt
[ec2-user@ip-172-31-xx-xx ~]$ grep ramesh /etc/passwd
[ec2-user@ip-172-31-xx-xx ~]$

ramesh's line, home and mailbox are gone. (ravi is still the leftover from Example 19.)

Why leftovers matter. Look at what can happen next. ramesh is gone and the leftover /home/ravi still belongs to 1001. Now create ramesh again. He gets UID 1001, the number ravi had, so the old folder is now his:

[ec2-user@ip-172-31-xx-xx ~]$ sudo useradd ramesh
[ec2-user@ip-172-31-xx-xx ~]$ id ramesh
uid=1001(ramesh) gid=1001(ramesh) groups=1001(ramesh)
[ec2-user@ip-172-31-xx-xx ~]$ ls -ld /home/ravi
drwx------. 2 ramesh ramesh 62 Jan  5 10:15 /home/ravi

Files belong to numbers, not names. useradd gives the next number after the highest one in use, so a number can come back when the newest users are deleted.

Example 22: cleaning up leftovers. If you already used plain userdel, remove the leftover folder and mailbox by hand (here, first sudo userdel -r ramesh again, so nobody owns it). Read the path twice before you press Enter; rm -rf asks nothing:

sudo rm -rf /home/ravi
sudo rm -f /var/spool/mail/ravi

14. The whole lifecycle on one page

What. Every command from this chapter, in order. All of them run as ec2-user (or another sudo user):

15. Try at home

Recap

Ravindra Bagale, trainer: linkedin.com/in/ravindra-bagale. The user names (ravi, ramesh) and file names are examples for learning. The commands and messages were checked on a test copy of Amazon Linux 2023 (sudo 1.9.15, shadow-utils 4.9, passwd 0.80, libpwquality 1.4.4) with the same sudoers, PAM and login.defs files as an EC2 server, and against an EC2 server's settings read-only. The hostname in the prompt, the dates, sizes and process numbers are illustrative.