# Why sudo is better than root On traditional Unix and Unix-like systems, the first and only user that exists on a fresh install is named `root`. Using the root account, you log in and create secondary "normal" users. After that initial interaction, you're expected to log in as a normal user. Running your system as a normal user is a self-imposed limitation that protects yourself from silly mistakes. As a normal user, you can't, for instance, delete the configuration file that defines your network interfaces, or accidentally overwrite your list of users and groups. You can't make those mistakes because as a normal user you don't have permission to access those important files. Of course, as the literal owner of a system, you could always use the `su` command to become the superuser (`root`) and do whatever you want, but for everyday tasks you're meant to use your normal account. That worked well enough for a few decades, and then came the `sudo` command. To a longtime superuser, the `sudo` command might seem superfluous at first. In a way, it feels very much like the `su` command. For instance, here's the `su` command in action: ```bash $ su root <enter passphrase> # dnf install -y cowsay ``` And here's `sudo` doing the same thing: ```bash $ sudo dnf install -y cowsay <enter passphrase> ``` The two interactions are nearly identical. And yet most distributions recommend using `sudo` instead of `su`, and most major distributions have eliminated the `root` account altogether. Is it a conspiracy to dumb down Linux? Far from it, actually. In fact, `sudo` makes Linux more flexible and configurable than ever, with no loss of features and in fact [several significant benefits](https://opensource.com/article/19/10/know-about-sudo). Here are three reasons you should be using `sudo` instead of `su`. ## 1. Root is a confirmed attack vector I use the usual mix of [firewalls](https://www.redhat.com/sysadmin/secure-linux-network-firewall-cmd), [fail2ban](https://www.redhat.com/sysadmin/protect-systems-fail2ban), and [SSH keys](https://opensource.com/article/20/2/ssh-tools) to prevent unwanted entry to the servers I run. Back before I understood the value of `sudo`, I used to look through logs with horror at all the failed brute force attacks directed at my server. Automated attempts to log in as `root` is easily the most common, and with good reason. Any attacker who knows enough to attempt a break-in also knows that essentially every Unix and Linux system had (at the time) a `root` account. That's one guess about how to get into your server an attacker doesn't have to make. The login name is always right, as long as it's `root`, so all an attacker needs is a valid passphrase. Removing the `root` account offers a good amount of protection. Without `root`, a server has no confirmed log in accounts. An attacker must guess at a login name. Not only that, but the attacker must also guess a password to associate with that guessed login name. That's not just one guess and then another guess, it's two guesses that must be correct at concurrently. ## 2. Root is the ultimate attack vector Another reason `root` is a popular name in failed access logs is because it's the most powerful user possible. If you're going to set up a script to brute force its way into somebody else's server, why waste time trying to get in as a regular user with limited access to the machine? It only makes sense to go for the most powerful user available. By being both the singularly known user name and the most powerful user account, `root` essentially makes it pointless to try to brute force anything besides it. ## 3. Selective permission The `su` command is all or nothing. If you have the password for `su root`, then you have the ability to become the superuser. If you don't have the password for `su`, then you have no administrative privileges whatsoever. The problem with this model is that a sysadmin has to choose between handing over the master key to their system, or withholding the key and all control of the system. That's not always what you want, as owner of a system. [Sometimes you want to delegate.](https://opensource.com/article/17/12/using-sudo-delegate) For example, you might want to grant a user permission to run a specific application that normally requires root permissions, but you don't want to give this user the root password. By editing the `sudo` configuration, you can allow a specific user, or any number of users belonging to a specific Unix group, to run a specific command. The `sudo` command requires a user's existing password, not your password, and certainly not the `root` password. ## 4. Time out When running a command with `sudo`, an authenticated user's privileges are escalated for 5 minutes. During that time, they can run the command or commands you've given them permission to run. After 5 minutes, the authentication cache is cleared and the next use of `sudo` prompts for a password again. This prevents a user from accidentally performing that action later (for instance, a careless search through your shell history, or a few too many **Up** arrow presses). It also ensures that another user can't run the commands, should the first user walk away from their desk without locking their computer screen. ## 5. Logging The shell history feature serves as a log for what a user has been doing. SHould you ever need to understand how something on your system happened, you could in theory use `su` to switch to somebody else's account, review their shell history, and get an idea of what commands a user has been executing. If you need to audit the behaviour of ten or hundreds of users, though, you might notice that this method doesn't scale. Shell histories also rotate out pretty quickly, with a default age of 1000 lines, and they're easily circumvented by prefacing any command with an empty space. When you need logs on administrative tasks, `sudo` offers a complete [logging and alerting subsystem](https://opensource.com/article/19/10/know-about-sudo) so you can review activity from a centralized location, and even get an alert when something significant has occured. ## Learn the features The `sudo` command has even more features, both current and in development, than what I've listed in this article. Because `sudo` is often something you configure once and then forget about, or else you configure only when a new admin joins your team, it can be hard to remember its nuances. Download our [sudo cheat sheet](LINK TO CHEATSHEET) and use it as a helpful reminder for all of its uses when you need it the most.