How to use sudo in Linux and master the sudoers file

If you use Linux daily, sooner or later you'll come across the command sudoIt's that prefix you see in front of many important commands, and it's almost always accompanied by a password request. Understand well what it does, how it works, and what risks it has. It's key to not accidentally breaking the system... and to working comfortably without constantly switching to root.

Instead of logging in directly as a superuser, the usual (and recommended) practice is to keep your normal user account and, only when necessary, temporarily increase privileges with sweatBehind that simple gesture lies a whole system of control over permissions, times, groups, and rules in the file. /etc/sudoers which is worth knowing in some detail, especially if you manage several users or servers.

What exactly is sudo in Linux?

The command sudo It is a tool that allows a user to run programs as if they were another user of the system, normally root (the superuser)but also any other account if configured that way. Although it is popularly said to mean "superuser do", many documentations also allude to the idea of “substitute user and do”: to temporarily replace the user under which a command is executed.

In any modern distribution (Debian, Ubuntu, derivatives, many based on SUSE, etc.), sudo comes pre-installed and is part of the normal administrative flow; you can consult Linux software tricksA standard user works with limited permissions, while the account root It has total control of the system. Using sudo provides an intermediate point: Specific users can perform administrative tasks without logging in as rootreducing risks and leaving a clear trail of what has been done.

One important detail is that, although sudo allows you to run commands as root, This does not necessarily mean that you assume all root privileges globally.What it does is grant privileges for each specific execution, following the rules defined in the configuration file. This allows for significant limitation of what each user can do with sudo.

This philosophy of not always working as root is essential in security. The less time you spend with full privileges, the less likely you are to break something or for malware to exploit your session.That's why sudo is such a prominent feature in the daily life of any Linux admin or advanced user.

How sudo works on a practical level

The basic usage is straightforward: you place sudo in front of the command you want to execute with elevated privileges. For example, to create a user from a normal account, you would use something like sudo useradd nombreIf you tried to throw useradd Without sudo, you would most likely get a permissions error or a "Permission denied".

When you invoke sudo For the first time in a terminal session, the system will ask you the password of the user you are logged in withnot the root password (except in special configurations in some distributions). If you enter it correctly and are authorized in /etc/sudoersThe command is executed with the privileges specified by the sudo rules.

By default, sudo authentication has a limited time validity, typically about 15 minutesAs long as you don't close the terminal session and that time hasn't passed, you can continue using sudo without being prompted for your password on every command. Once the time limit expires, the next sudo command will require it again.

All this behavior is defined and controlled in the file. /etc/sudoers and in the files included in /etc/sudoers.d/. Only users and groups listed there with appropriate permissions can run sudoThis allows for very fine-tuning who can do what, on which machines, and under what commands.

General syntax of the sudo command and key options

The most common way to use sudo is as simple as:

sudo comando

Under the hood, sudo accepts several options that allow you to check privileges, view the version, force password checks, and more. Some of the most common ones in many distributions are:

• -h: displays a brief help message with the syntax and main options available in sudo.
• -V: displays version information and compilation details of the sudo program.
• -v: renews the authentication “ticket”, extending the validity period without needing to execute a privileged command itself.
• -k: invalidates current sudo privileges, so the next time you use it, it will ask for your password no matter what.
• -l: list What privileges does the current user have? depending on the sudoers configuration (what commands it can execute, on which hosts, as which users, etc.).

From here, you can combine sudo with virtually any command that requires administrator privileges: Package managers, network tools, system services, user account utilities, file ownership changes…the list is practically endless.

Practical examples of using sudo

One of the most common operations that requires elevated privileges is the manage software packagesIn SUSE-based distributions, it is commonly used zypper, whereas in Debian/Ubuntu, the following is used aptIn both cases, when the operation modifies the system (install, update, remove), you need sudo.

For example, to install a package with zypper you would use something like this sudo zypper install nombre-paqueteand with apt something like sudo apt-get update followed by sudo apt-get upgradeIf you try to update without sudo, you will see system file lock or permission errors, because only a user with the appropriate privileges can access those directories.

Another very common combination is sweat with systemctlThe tool for managing services on systems with systemd. To start or restart a service like Apache, for example, you would use something like sudo systemctl restart apache2However, checking the status of a service, which does not involve changes, can often be done without sudo: systemctl status NetworkManager It is usually accessible with normal permissions.

When you need to modify user accounts, the classic command is usermodYes, always under sweat. For example, you could define the number of days after the password expires before an account is deactivated, with a type order sudo usermod -f 30 nombreusuario, where 30 would be the margin days.

Another area closely linked to the south is that of Change the ownership of files and directories with chownIf you want a certain user to become the owner of an entire tree under /home/test/tux-filesYou would launch something like sudo chown -R tux /home/test/tux-filesThen, you could verify the result with a ls -l to verify that the property has been updated correctly.

Run commands like other users with sudo (-u, -s, -i)

In addition to executing commands as root, sudo allows launch commands like other specific usersTo do this, the option is used -uA simple example would be checking the actual user who executes a command:

whoami returns your current user, while sudo -u pedro whoami It would show "pedro" if your configuration allows you to act as that user. This method is very useful for testing permissions, paths, or environments without having to fully log in to that account.

When you want a interactive shell With high privileges, two very typical variants come into play: sudo -s y sudo -iThe first one opens a shell as the target user, but inheriting the current user's environment (variables, current directory, etc.). The second mimics a login shell of the target user, loading its startup scripts and using its $HOME directory.

For example, if you run sudo -s -u tuxYou would appear with a shell like tux, but from the directory you were in before, with much of your environment intact. In contrast, with sudo -i -u tux You would enter a session much more like if Tux had logged in directly, with his profiles (.profile, .bash_profile, etc.) loaded.

In both cases, The executed commands are recorded in the historywhich is interesting from a traceability point of view: you can always review what was done with high privileges, who did it and when.

Differences between sweat and his

In Linux, both su , the sudo They allow you to execute commands with the privileges of another user, most often root, but the way you work with each is quite different. Understanding this difference helps you decide when to use each option.

The command su (substitute user) is used for switch users within the same terminal. If you do su pedroYou will be asked for Pedro's password; upon entering it, your shell will be under that account. The original user's session does not disappear; it remains "beneath" the new one. When you type exitYou leave Pedro's session and return to the previous one.

If you use su without specifying user, by default Try switching to root, asking for the root password. This has a significant practical effect: many people end up working as root for long periods, with all the risks that entails, simply because it's more convenient than constantly typing `sudo`.

In contrast, Sudo proposes another approach: You don't permanently change your session or user.Instead, you elevate your privileges only for specific commands (or a specific shell). Authentication is done with your own password, and control over who can do what is managed centrally in sudoers.

Therefore, in environments where security is a priority, it is not advisable to log in directly as root or always work with `su`, and it is preferred to use `sudo` instead. use sudo systematicallyThis way, every privileged action is audited, reducing the potential damage from a poorly executed command or exploit.

The /etc/sudoers file: the heart of sudo configuration

All of sudo's behavior (who can use it, such as which users, on which hosts, and with which commands) is defined in the file. /etc/sudoers and in the files included from there, usually by means of a directive of the type #includedir /etc/sudoers.dIt's a very sensitive file: A syntax error can leave you without sudoso it should be handled with care.

A typical example of content you'll see in sudoers is a line like root ALL=(ALL:ALL) ALLThis means that the root user can execute any command on any machine, just like any other user and group. Group-based rules are also common, such as %sudo ALL=(ALL:ALL) ALL o %admin ALL=(ALL) ALL, where the prefix % indicates that it is a group within the system.

The idea is that all users who are part of the sudo or admin group They inherit those privileges to use sudo. Thus, in Ubuntu, the first user created during installation is usually automatically added to the sudo group, having full administrative permissions without having to use the root account directly.

Another common practice is to avoid touching the main file too much and instead create specific files within /etc/sudoers.d/Thanks to the line #includedir /etc/sudoers.dAny valid file within that directory is loaded as part of the total sudoers configuration, making it easy to organize rules by services, departments, projects, etc.

How to safely edit sudoers with Visudo

To modify sudoers, you can't just open it with your favorite editor, because A syntax error can block sudo and leave you in a real mess. The correct way is to always use the command visudo, which is responsible for opening the file in an editor (vi, nano, whatever you have configured) and, when saving, checking that the syntax is correct before applying the changes.

If you want to edit the main file, simply launch sudo visudoIf what you need is to create or modify a specific file within /etc/sudoers.d/You can indicate this with the option -f, For example: sudo visudo -f /etc/sudoers.d/networkingThis keeps the overall file cleaner and reduces the risk of messing it up.

When you review sudoers, you'll come across many commented lines that begin with #Those are explanations or rules disabledOne in particular is often interesting in several distributions: the one that begins with %wheelIf you remove the # From that line, and if you add users to the wheel group, you will be granting them sudo rights according to what that rule dictates.

As a matter of experience, it's a good idea to always have another root session or a console with a shortcut open while you're working on sudoers in case something goes wrong. Breaking sweat without having an alternative way to correct it It can leave you unable to use elevated privileges from your normal user account, forcing you to resort to rescue modes.

Manage who has sudo: groups and users

In daily practice, the most convenient way to decide who can use Sudo with full powers is usually through administrative groupsAs mentioned, it is very common to have a group called sudo o admin o wheel, whose rules in sudoers give broad privileges to its members.

To see who is part of the sudo group in a typical system, you can use a grep about /etc/group: For example, grep 'sudo' /etc/group It will list the users who are currently in that group. It's a quick way to see who has potential access to sudo.

If you want a specific user, let's say billIf you have sudo privileges, one option is to add it to the corresponding group using commands like adduser bill sudo or the equivalent in your distro. From that moment on, and according to the sudoers rules for that group, Bill will be able to use sudo like the rest of the administrators.

Similarly, if at any point you need to revoke those permissions, you can remove him from the group, for example with deluser bill sudoOnce that operation is complete, Bill will no longer be able to perform actions that require sudo, unless he has some additional specific rule in sudoers.

This approach of delegating sudo control to groups is very useful when managing multiple users or a work teambecause it allows you to grant and revoke permissions centrally without having to constantly edit the sudoers file for each individual name.

Grant specific permissions with sudoers (without giving "free rein")

Sometimes you don't want a user to have full root accessbut only to a small set of commands. That's where sudoers becomes especially powerful, because it allows you to define command aliases and very specific rules for groups or users.

Imagine you want to create a group, for example netadmin, whose members can execute certain network commands (such as tcpdump or web server management) with privileges, but nothing more. You could define command aliases in a file of /etc/sudoers.d/ of this type, using Visudo to edit it.

Within that file, aliases can be declared as Cmnd_Alias CAPTURE = /usr/sbin/tcpdump for traffic captures or an alias Cmnd_Alias SERVERS = /usr/sbin/apache2ctl, /usr/bin/htpasswd to manage the web server and related passwords. Then, a more general alias like NETALL = CAPTURE, SERVERS It combines both.

From there, the rule %netadmin ALL=NETALL This indicates that any user in the netadmin group can execute all commands included in NETALL (i.e., those in CAPTURE and SERVERS) with sudo. The next step would be to add bill to the netadmin group with something like sudo adduser bill netadmin, and ready.

The key is that Only those specific commands will be executed with privilegesIf Bill tries to use sudo for anything not covered by NETALL, the system will deny it. This is a highly recommended approach when you want to distribute technical responsibilities without granting full administrator access.

Allow sudo without a password in very specific cases

Another common scenario is wanting a user to be able to execute a single command with sudo without needing to enter the passwordThis can be useful for specific scripts or utilities that are launched frequently and where it doesn't make sense to repeat authentication over and over again.

The safest way to approach this is to encapsulate that command in a script owned by root, with restricted permissionsFor example, you create a comando.sh, and then you adjust its owner and permissions with something like sudo chown root:root comando.sh y sudo chmod 700 comando.shThat way, only root can modify and run it.

Then, in sudoers, you define a rule so that the user in question can execute comando.sh No password. Something like nombredeusuario ALL=(ALL) NOPASSWD: /home/nombredeusuario/comando.sh It would allow that user to launch the script with sudo without being prompted for the password.

It is important to insist that It is not advisable to abuse the NOPASSWD rulesEvery time you allow `sudo` without a password, you're opening a door that could be exploited if someone gains access to the user or manipulates the context in which the command is executed. It's best to use them only for very specific and audited cases.

Even so, for repetitive and automated tasks, or for certain highly controlled commands, this technique is extremely practical. The key is to limit the scope: It's better to grant sudo without a password to a very specific command than to a complete command interpreter..

Alternatives and complements to sudo: doas and other approaches

It's becoming popular in some circles. doas as a lightweight alternative to sudo. Its philosophy is similar (allowing the execution of commands with another user's privileges), but with a simpler configuration and a very small binary, something that fits especially well in minimalist systems.

DOAS is not usually installed by default, so you would have to add it from the package manager and then create the configuration file. /etc/doas.confA simple example of a rule would be something like this: permit nopass manz, which authorizes the user manz to use doas without entering a password to elevate privileges to administrator.

Unlike sudoers, where you can define aliases and fairly complex rules, doas opts for a smaller set of directivesprioritizing simplicity. You can set specific permissions, explicitly deny, limit commands, etc., but without the same amount of "flourish" that sudo allows.

It's not about one being better than the other in absolute terms, but about In some cases, two may be sufficient and more convenient.While in large or highly granularly controlled environments, sudo remains the most flexible and well-known option.

Whichever tool is chosen, the underlying idea is the same: not working as root all the timebut use controlled privilege escalation mechanisms, with clear rules and logs of what is done.

With all this, it is clear that the sudo command is much more than just a prefix before "dangerous" commands: It is a central component of security and daily administration in LinuxUnderstanding your options, mastering the sudoers file, knowing when to use it, how to limit specific commands, or when to allow exceptions without a password gives you much finer control over your system and what other users can do on it.