Managing users and groups in Kali Linux for security work

Key takeaways

• Kali has used a non-root default user since the 2020.1 release; use sudo for privileged commands.
• useradd, usermod, groupadd and visudo work the same as on other Debian-based systems.
• Create separate accounts for separate projects or team members on a shared Kali instance.
• Most security tools do not need root; run them as a normal user unless they specifically require it.
• Review sudoers carefully on a shared or team Kali box.

Why does this differ from generic Linux user management?

The commands are the same as any Debian-based system. What is specific to Kali is the context: Kali is a testing platform, often shared, often connected to sensitive engagements, and historically associated with running as root. Since the 2020.1 release, Kali ships with a standard, non-root user by default, and privileged actions go through sudo. Confirm this is still the behaviour on the version you are running, since defaults can change; the Kali Linux documentation states the current default.

How do you create and manage users?

$ sudo useradd -m -s /bin/bash project-alpha
$ sudo passwd project-alpha
$ sudo usermod -aG sudo project-alpha # if this account needs admin rights

• -m creates a home directory.
• -s /bin/bash sets the shell.
• Add to the sudo group only if the account genuinely needs it.

To remove an account when an engagement ends:

$ sudo userdel -r project-alpha

-r removes the home directory too. Make sure you no longer need anything in it first.

How do groups work?

Groups let you assign permissions to several users at once.

$ sudo groupadd pentest-team
$ sudo usermod -aG pentest-team analyst1
$ groups analyst1

Use groups to control access to shared tool configurations, captured evidence directories or project folders, rather than giving every user individual permissions.

Why create separate accounts on a shared Kali box?

• Accountability: command history and logs tie to a specific account.
• Isolation: one user's broken configuration does not affect another's.
• Scoped access: a junior tester's account can be limited while a lead's has broader rights.
• Clean handover: removing an account at the end of an engagement is simple.

How do you manage sudo access carefully?

Edit sudoers safely with visudo, which checks syntax before saving:

$ sudo visudo

On a shared training or team machine, consider limiting which commands a junior account can run with sudo, rather than giving blanket admin rights, using a specific rule in /etc/sudoers.d/.

Why should most tools not run as root?

Running every tool as root out of habit increases the damage a mistake or a malicious package could cause. Many Kali tools work fine as a normal user; some specific ones, like raw packet capture or certain exploitation modules, genuinely need elevated privileges, and sudo grants that only for the command that needs it.

What mistakes do testers make?

• Logging in as root out of habit, carried over from very old Kali images.
• Sharing one account and password across a whole team.
• Adding every user to sudo without thinking about what they actually need.
• Forgetting to remove accounts after an engagement.

Where does this fit in your learning?

These are core Linux administration skills applied to a security context. Build the base with our Linux course and see the general reference on managing users and permissions in Linux.

Next steps

For the general Linux reference, see Linux user and group management. To build broader Kali skills, see our KLCP course.

Related reading

• How to Manage File Permissions in Kali Linux? The Complete Guide