Use an existing authorized administrator and keep that session open. Define whether the new operator needs full system administration or only a narrow task. Commands that launch shells, editors, package scripts or arbitrary files can grant much broader power than their names suggest.

1. Create the named account using the distribution-supported user-management tool, with its own home and appropriate shell. Set credentials or install an approved SSH public key through a controlled channel.
2. For a full administrator, use the distribution's intended administrative group after reviewing its sudo policy. Debian/Ubuntu commonly use sudo; AlmaLinux/Rocky commonly use wheel. Do not assume membership has identical effects everywhere.
3. For restricted work, create a narrowly scoped policy through visudo or its drop-in editing option. Specify the intended executable, user and safe argument constraints rather than a broad wildcard.
4. Run visudo -c to validate the complete policy. Preserve correct ownership and mode on sudoers files.
5. Start a fresh login as the new user, inspect sudo -l, and test the permitted action. Also confirm a harmless action outside the policy is denied.
6. Record the account owner and review date, then remove obsolete access through a separate tested change.

After an administrator creates a scoped sudo policy, sign in as the intended user on the Linux server and inspect its privileges. The first command shows the current account identity and groups. The second lists the commands the account may run through sudo.

id
sudo -l

Read the result: Compare the displayed run-as user, exact executable paths, arguments and authentication requirements with the approved task. Membership in a group alone is not a complete statement of sudo access. A wildcard, shell-capable program or writable helper can grant more power than its short command name suggests.

Validate policy syntax with the administrator's supported visudo workflow before deployment. Test the intended operation using a harmless read-only action where possible. If the listing allows far more than the job requires, narrow the policy before distributing the account to automation or support staff.

Often it is not. Editors and many utilities can execute commands or modify privileged files. Use a carefully designed task-specific interface when full root-equivalent administration is not intended.

Confirm ordinary commands run as the user and privileged actions require the intended authentication. Check logs identify the individual operator. Ensure unrelated files, credentials and services remain inaccessible under the restricted role.

If sudo fails, inspect group membership in the new session, policy ordering and command paths. Do not add blanket NOPASSWD access to fix a narrow mismatch. If a policy edit breaks access, recover through the still-open administrator session or console and revalidate before testing again.

• Installing an SSH key without losing existing server access
• Testing SSH configuration before reloading the service
• Recovering from an SSH lockout using the server console
• Changing an AlmaLinux or Rocky Linux address with NetworkManager

• Debian manual: Sudoers.5.en
• Ubuntu: User Management