Visudo under Linux: modifying sudoers without losing root access

An error in /etc/sudoers can remove your last administrator access while the SSH session is still running. The risk often stems from a poorly written rule, an incorrect command path, or a file added too quickly to /etc/sudoers.d.

I never edit sudoers with an editor launched directly on the file. visudo Lock the configuration during editing and check its syntax before saving. On a remote server, also keep a second root session open until the final test. This safety net is just as important as the command itself.

First, confirm that your account still has sudo privileges and check which commands it is authorized to use:

sudo -v
sudo -l
id
groups

sudo -v validates authentication information without launching a sensitive command. sudo -l displays the rules actually applied to the account. If this step fails, do not touch sudoers from this session.

Next, open a second terminal and maintain a root session there:

who
w

Do not close this session while editing. On a remote machine, also check your console, KVM, or rescue panel access. The guide on the Linux accounts and groups can help you confirm the target account before granting it privileges.

Save sudoers without changing its permissions

Before editing, copy the main file to a folder reserved for root. The option -has retains, in particular, the owner, the group and the mode:

sudo cp -a /etc/sudoers "/root/sudoers.backup-$(date +%F-%H%M)"
sudo stat -c '%A %a %U:%G %n' /etc/sudoers /etc/sudoers.d

On many distributions, /etc/sudoers belongs to with a mode four hundred fortyDo not correct permissions randomly if your distribution uses a different policy. First, note the current state and keep the exact path to the backup.

Edit the main file with visudo

To open the main configuration, simply launch:

sudo visudo

It creates a lock to prevent two concurrent edits. Upon closing, it analyzes the syntax and normally refuses to install an invalid configuration. If the tool reports an error, return to the editor and correct it. Do not force the saving of a file you do not understand.

A sudoers rule typically follows this logic: user or group, hosts involved, execution identity, and then authorized commands. To authorize the account alice To restart and check only Nginx, first verify the binary path:

command -v systemctl

If the command returns /usr/bin/systemctlThe rule can take this form:

alice ALL=(root) /usr/bin/systemctl is-active nginx, /usr/bin/systemctl restart nginx

Do not use NOPASSWD Out of habit. For automation, limit it to a single account, a single command, and controlled arguments. A broad rule granting access to a shell, editor, or command that can launch other programs often amounts to giving full root access.

Create a clean file in /etc/sudoers.d

For a rule specific to a department or team, I prefer a separate fragment to the large main file. Open it with the option -f :

sudo visudo -f /etc/sudoers.d/administration

Choose a simple name, without spaces, periods, or saving characters, such as ~According to the directive @includedir Used by the distribution, some names may be ignored. After registration, check the owner and mode:

sudo chown root:root /etc/sudoers.d/administration
sudo chmod 0440 /etc/sudoers.d/administration
sudo stat -c '%A %a %U:%G %n' /etc/sudoers.d/administration

sudo on Linux details the delegation by users, groups and aliases. Here, the objective remains narrower: to install a verifiable rule without losing the ability to revert to the previous version.

Confirm the entire configuration before testing.

Once the editing is complete, run a full check. This command verifies the main file and the includes it references:

sudo visudo -c

The result should indicate that the analyzed files are syntactically correct. If a fragment is reported, reopen that exact file with visudo -fDo not restart the machine or close the root session while the check is failing.

From the retained root session, then display the rights of the target account:

sudo -l -U alice

This reading allows you to identify a rule that has not been loaded, an incorrect username, or a much broader authorization than expected.

Test in a new session before closing root

Open a third login with the account in question. Do not simply use the session that already has a cached sudo ticket. Invalidate this cache, request the list of privileges, and then run only the authorized command:

sudo -k
sudo -v
sudo -l
sudo systemctl status nginx

Also verify that an unexpected command is still refused. A rule is correct if the user retains the expected access without gaining more privileges than necessary. Close the backup root session only after this test.

Restore sudoers if validation or access fails

If visudo -c If the fails, correct the faulty fragment from the still-open root session. To revert to the main saved file, replace the path with your actual backup:

cp -a /root/sudoers.backup-YYYY-MM-DD-HHMM /etc/sudoers
visudo -c

If all administrator sessions are already closed, use the vendor console, recovery mode, or a live environment to mount the system and repair the configuration. Editing sudoers from an account without privileges will not work.

To understand a refusal after successful validation, check the sudo events of the current startup, and then the authentication log if your distribution uses it:

sudo journalctl -t sudo -b --no-pager
sudo tail -n 100 /var/log/auth.log

There Visudo manual page documents the locking, control and option -f. Documentation sudoers(5) This describes the syntax, inclusions, and command rules. Above all, maintain this order: backup access, save, edit with

sudo apt update && sudo apt upgrade