A service account with an interactive login, or a developer account with permanent administrator access, can do more than its job requires. Secure Linux account management starts with a practical question: what does this identity need to do? Its groups, login options, and privileges should follow from the answer.
What a Linux account represents
Linux assigns each user a numeric user ID (UID) and each group a numeric group ID (GID). Names make accounts easier to manage, but the kernel checks ownership and permissions using those numeric IDs. A user has a primary group and may also belong to supplementary groups. The first ordinary user often has a UID such as 1000, depending on the distribution; do not assume that value applies everywhere.
Local account definitions usually live in /etc/passwd. Despite its name, this file does not normally contain password hashes. Its entries include a login name, UID, primary GID, home directory, and login shell. Password hashes and aging settings are stored in /etc/shadow, which requires privileged access. Local groups appear in /etc/group, with related protected group data potentially in /etc/gshadow. These files help explain how an account is set up, but use account-management tools for routine changes rather than editing them by hand.
Not every identity is local. A workplace machine may get accounts from a directory service, and name-service configuration can combine multiple sources. To check an account, getent passwd alice and id alice are more useful than searching only /etc/passwd. The first queries the configured name service; the second shows the UID, primary GID, and group memberships currently resolved for that user.
Human accounts and service accounts have different jobs
A human account normally needs a home directory and a usable shell. A service account lets a process run under its own identity instead of running as root. It may need a home directory for application data, but it usually should not have an interactive login shell. A shell restriction alone does not limit what the running service can access, though: its configuration, logs, and data also need appropriately narrow permissions.
The root account has UID 0 and can administer the system. Some environments allow direct root login; others disable it and expect administrators to use sudo. For routine work, named personal accounts make it easier to trace changes. Avoid shared logins: they obscure who changed a setting and make it harder to remove one person’s access without affecting everyone else.
Before creating an account, decide whether it is for a person or a service, whether it needs interactive login, which groups it needs, and how it will be retired. Otherwise, it is easy to grant broad access to get a task working and never revisit it.
Create and inspect accounts with the right tools
Account tools vary by distribution. On many systems, useradd is the lower-level command; some distributions also provide an interactive adduser wrapper. For example, sudo useradd -m -s /bin/bash alice creates a local account with a home directory and Bash as its shell. An administrator can then set a password with sudo passwd alice. Defaults vary, including whether the system creates a private primary group, so check the result.
Use getent passwd alice to inspect the account entry and id alice to check its identities. Where supported, sudo passwd -S alice shows password status; output and available options vary by distribution. A locked password does not rule out access through another authentication method, so this check is not a complete login audit.
For an existing account, sudo usermod -s /bin/bash alice changes its login shell. Make sure the shell exists and suits the user. Moving a home directory or changing a UID needs more planning: consider file ownership, active processes, scheduled jobs, and applications that may refer to the old path or numeric ID. On a shared machine, schedule that work for a maintenance window.
Use groups to grant specific access
Groups can provide access to a resource without making every user an administrator. A developer who edits a team-owned project, for instance, can belong to that project’s group. But groups that control containers, devices, or system services may confer more power than their names suggest. Check what membership actually permits before adding anyone.
On systems using usermod, add an existing user to a supplementary group with sudo usermod -aG projectteam alice. The -a flag matters: -G without -a replaces the user’s supplementary group list. Check the result with id alice. Existing login sessions may keep their previous group set until the user starts a new session.
Membership does not automatically grant access to every project file. The resource must be configured to allow that group access too. Decide who needs access, then set permissions on the relevant resource.
Delegate administration without handing out root
sudo can authorize named users or groups to run administrative commands. Many distributions provide an administrative group, often called sudo or wheel, but membership commonly grants broad control. Check the policy on the machine rather than assuming those names mean the same thing everywhere.
For a narrow duty, a carefully scoped sudo rule may be better than full administrative membership. Edit sudo configuration with visudo, or manage a file under /etc/sudoers.d using the same validation workflow. A syntax error can block administration. Limit the permitted command and arguments as precisely as the task allows. Editors, shells, package managers, and commands accepting arbitrary file paths deserve particular care: a rule that looks limited may still allow broad system changes.
Do not make NOPASSWD the default just to avoid a prompt. The password prompt is no substitute for access control, but it can slow an accidental privileged action. And having sudo does not mean working from an administrative shell all day. Run ordinary development commands as the ordinary user, and use privilege only for the operation that requires it.
Understand login controls and their limits
An account’s shell affects whether it can start a conventional interactive session. Service accounts often use /usr/sbin/nologin or an equivalent path supplied by the distribution; confirm the path on the host. A non-login shell is useful for a service identity, but it does not stop a program already running as that identity from accessing resources available to it.
Password locking, account expiration, and SSH settings control different parts of access. On many systems, sudo passwd -l alice locks the account’s password, but SSH keys or other authentication methods may still work. An expiration date can provide broader control for temporary access; use your distribution’s supported account-aging tools and verify the result. Review the SSH server’s settings separately, including whether direct root login and password authentication are allowed. Before disabling a working access method, test an alternative and keep a recovery route.
Linux uses pluggable authentication modules (PAM) to apply authentication and account policies to services such as login and sudo. Password requirements, lockout behavior, and session handling may be configured there or through a distribution tool. Do not copy a PAM change from another distribution without checking the local configuration. Keep a separate administrative session active while testing it.
Review access as a lifecycle, not a one-time setup
Start an access review with the people and services that should still exist. For each human account, check its current role, resolved groups, administrative rights, SSH access, and owned scheduled tasks. Compare service identities with the processes expected to run under them. If identities are centrally managed, check whether removing directory access also removes local keys, cached access, and application-specific credentials.
When someone leaves a team, disabling login promptly is usually safer than deleting the account immediately. Files may still be owned by its UID, and jobs or applications may depend on it. Preserve data according to your organization’s policy, stop or transfer scheduled tasks, and remove authorized SSH keys and application access before deciding whether to archive or delete the account. Be careful with userdel -r: on systems that support it, the option removes the account and its home directory, potentially destroying needed files. Deletion also does not find every file the account owns elsewhere.
For a temporary collaborator, record the intended end date when granting access. On the review date, run id username to check current groups, verify whether the account can still authenticate through methods your system supports, and remove access the project no longer requires. That last check matters: a group membership or login method can remain long after the original task is done.
