Linux Accounts and Restricted sudo Access

Authentication and command privileges differ

A support user needs to inspect Nginx without being able to restart it. Creating an account and adding it to the sudo group grants too much for that job. Linux account identity, login methods and command privileges need separate controls. This tutorial builds a limited role, tests allowed and denied commands, and covers access removal when the user leaves.

Local account and administrator access

Commands target Ubuntu 24.04 LTS with sudo and OpenSSH. Check the local systemctl path. For LDAP or SSSD users, also inspect organizational identity policy.

No extra compute allocation is required. Keep an administrator console and known-good sudoers configuration for policy recovery.

opsreader is an example name. Check account existence and group memberships first. A restricted rule does not cancel broader privileges granted by another group.

sudo membership and password locks

usermod -aG sudo usually grants broad access and does not fit this status-only role. Passwd -l locks the password. Disabling every login path also involves SSH and identity policy.

Restricted commands and escape paths

Shells, editors and package managers often execute root code. Broad wildcards are not restricted privileges. --no-pager keeps the example out of an interactive pager. Avoid unnecessary interactive service-account login. Revoke keys, directory access, API tokens, cron, sudo and sessions independently.

Create the account and validate the rule

Check whether the account exists before creating it, avoiding duplicate identities or unintended privileges. If opsreader is absent, create it without sudo-group membership. Locate systemctl on this host as well; the rule must refer to that exact binary path.

getent passwd opsreader
sudo adduser opsreader
id opsreader
command -v systemctl
sudo visudo -f /etc/sudoers.d/opsreader-nginx

This is the complete rule. Match the binary path to the host. --no-pager avoids interactive-pager shell escapes.

opsreader ALL=(root) /usr/bin/systemctl --no-pager status nginx.service

sudo chmod 440 /etc/sudoers.d/opsreader-nginx
sudo visudo -cf /etc/sudoers
sudo -l -U opsreader
sudo -u opsreader sudo /usr/bin/systemctl --no-pager status nginx.service

After saving the rule, visudo must accept the syntax and sudo -l should show only the intended grant. In staging, use the target account to test status and verify that restart is denied. An inactive Nginx service can make status return a nonzero code; distinguish service state from a privilege denial.

Audit account and privilege changes

Retain sudo and SSH events centrally. Audit changes to passwd, group and sudoers.d with appropriate policy. Compare UID-zero accounts against the approved list.

Privilege failure or service failure?

For Permission denied, inspect sudo -l and check the file with visudo -cf. A nonzero status result may simply describe an inactive service. If an account still logs in after its password is locked, follow the authentication path: an SSH key or another identity method may remain authorized.

sudo -l -U opsreader
sudo chage -l opsreader
loginctl list-sessions
getent group sudo
sudo journalctl _COMM=sudo -n 50 --no-pager

Compare current session groups with new policy. Identity caches and existing sessions might delay changes. Confirm UID and running jobs before terminating sessions.

Undo a rule and retain user data

To revoke this grant, move its dedicated file out of sudoers.d and validate the remaining policy with visudo. Retain UID/GID and policy history, protecting shadow and keys with encryption. During offboarding, revoke access first and retain HOME until data handover and retention requirements are settled.

Positive and negative permission tests

Test permitted and forbidden commands as the target user in staging. Keep emergency credentials in a vault and rule changes in access-management records.

Best Practices

Conclusion