While both sudo and su commands elevate privileges, they work in fundamentally different ways and serve distinct purposes in system administration. Here's how.
Publish date: 12/19/2025
If you've spent any time managing a Linux server, you've probably encountered both sudo and su. At first glance, they might seem like two ways to do the same thing—gain elevated privileges. But there are important differences between them that affect security, logging, and how you work with your system.
Let's break down what each command does, when you should use one over the other, and how to configure them properly on your server.
The sudo command stands for "superuser do." It allows permitted users to execute commands as the root user (or another user) without actually logging in as root. When you use sudo, you're temporarily borrowing root privileges for a single command.
Here's a basic example:
sudo apt update
This runs apt update with root privileges, but only for that one command. After it completes, you're back to your regular user account.
The behavior of sudo is controlled by the /etc/sudoers file, which specifies who can use sudo and what they're allowed to do with it. You should always edit this file using the visudo command rather than opening it directly—visudo checks for syntax errors before saving, which prevents you from accidentally locking yourself out of sudo access.
One of the most useful features of sudo is that it logs every command executed with elevated privileges. These logs typically go to /var/log/auth.log on Debian-based systems or /var/log/secure on RHEL-based distributions. This creates an audit trail that's valuable for security and troubleshooting.
The su command stands for "substitute user" or "switch user." Unlike sudo, which runs individual commands with elevated privileges, su actually switches your entire session to another user account—usually root.
Here's how it works:
su
After entering the root password, you're now operating as the root user. Every command you run from this point forward has root privileges until you type exit or press Ctrl+D.
You can also switch to a non-root user:
su - username
The hyphen (or -l flag) starts a login shell, which means it loads that user's environment variables and settings. Without the hyphen, you switch users but keep your current environment, which can sometimes lead to unexpected behavior.
Unlike sudo, su doesn't provide detailed logging of individual commands. The system logs that you switched users, but not what you did afterward. This makes it harder to audit actions taken with elevated privileges.
The fundamental difference comes down to scope and approach. With sudo, you're executing specific commands with temporary elevated privileges. With su, you're switching your entire session to another user account.
Security-wise, sudo has several advantages. First, users don't need to know the root password—they authenticate with their own password. This means you can grant elevated access without sharing credentials. Second, the sudoers configuration lets you grant granular permissions. You can allow a user to restart services but not install packages, for example.
The logging difference is significant too. When someone uses sudo, the system records exactly what command they ran, when they ran it, and which user executed it. With su, you only know that someone switched to root, not what they did afterward.
There's also a practical safety aspect. Because sudo requires you to prefix each command with sudo, it gives you a moment to think about whether the command really needs root privileges. When you're logged in as root through su, every command runs with full privileges—including accidental ones like typos that could damage your system.
For most day-to-day system administration tasks, sudo is the better choice. It's safer, provides accountability, and follows the principle of least privilege—users get elevated access only when they need it and only for the duration of a single command.
Sudo is particularly good for:
apt install or dnf updatesystemctl restartMany modern Linux distributions, including Ubuntu, don't even enable the root account by default. Instead, they encourage sudo-only administration, which is generally considered a security best practice.
You can also use sudo -i or sudo -s to start a root shell if you need to run multiple commands with elevated privileges. This gives you a root environment while still logging the initial sudo invocation.
There are situations where su makes more sense, though they're less common in modern system administration.
If you're performing system recovery or maintenance where sudo isn't working (maybe because the sudoers file is misconfigured), you need su to get back into the system. Similarly, some older scripts or software might expect to run as the root user rather than through sudo.
Su is also useful when you need to test something from another user's perspective, complete with their full environment:
su - testuser
This is helpful for debugging permission issues or verifying that a user's environment is configured correctly.
In enterprise environments, you might encounter systems where direct root access is required for certain administrative tasks. However, these situations are becoming less common as organizations adopt modern security practices. If you're setting up SSH access on a new server, configuring sudo properly should be one of your first steps.
To grant sudo access to a user, you add them to the appropriate group. On Debian and Ubuntu systems, that's the sudo group:
sudo usermod -aG sudo username
On RHEL-based systems like Rocky Linux or AlmaLinux, use the wheel group instead:
sudo usermod -aG wheel username
The user will need to log out and back in for the group membership to take effect.
For more granular control, you can edit the sudoers file with visudo and add specific rules. For example, to let a user restart services without entering a password:
username ALL=(ALL) NOPASSWD: /bin/systemctl restart *
This kind of targeted permission is one of sudo's strengths. You can give users exactly the access they need without handing over full root privileges.
When configuring sudo on production servers, consider setting a timeout for how long sudo "remembers" your password. The default is usually 15 minutes, but you might want to shorten this on sensitive systems. You can also disable password caching entirely, though this becomes tedious if you're running many commands in succession.
For more comprehensive server security, you should also secure your SSH configuration and consider implementing Fail2Ban to prevent brute force attacks.
Here are some practical examples you'll use frequently:
Run a single command as root:
sudo systemctl restart nginx
Edit a system file:
sudo nano /etc/ssh/sshd_config
Start a root shell with sudo:
sudo -i
Switch to root with su:
su -
Switch to another user:
su - username
Run a command as a different user with sudo:
sudo -u postgres psql
Check what sudo permissions you have:
sudo -l
That last command is particularly useful—it shows exactly what you're allowed to do with sudo according to the sudoers configuration.
Whether you use sudo or su, following security best practices makes your system more resilient against unauthorized access and accidental damage.
Never log in as root through SSH directly. Disable root SSH access in /etc/ssh/sshd_config by setting PermitRootLogin no. This forces attackers to guess both a username and password, rather than just targeting the root account.
Use strong passwords for all accounts that have sudo access. Better yet, implement SSH key-based authentication and disable password login entirely.
Regularly review your sudoers configuration to make sure users only have the permissions they need. Remove sudo access from accounts that no longer require it.
Consider using two-factor authentication for sudo commands on particularly sensitive systems. This adds an extra layer of protection even if a password is compromised.
Finally, monitor your authentication logs regularly. Unexpected sudo usage or failed su attempts can indicate someone trying to gain unauthorized access to your system. Setting up a firewall with UFW adds another layer of defense.
Sudo is generally safer because it doesn't require sharing the root password, provides detailed logging of every command executed with elevated privileges, and encourages the principle of least privilege. With su, once you switch to root, every command runs with full privileges until you exit, which increases the risk of accidental system damage.
Yes, you can configure specific commands to run without a password prompt by adding NOPASSWD to the sudoers file. However, this should be used sparingly and only for specific, non-destructive commands. For most administrative tasks, requiring password authentication provides an important security check.
Ubuntu and many other modern distributions disable the root account by default to encourage the use of sudo instead. This improves security by eliminating a common target for attackers and ensuring all administrative actions are logged with accountability. You can still use sudo -i or sudo -s when you need an interactive root shell.
If you're already root (or using sudo), you can switch to another user without their password using su - username. Regular users cannot switch to other accounts without knowing the target account's password, unless they have sudo privileges configured to allow it.
The hyphen creates a login shell for the target user, which loads their complete environment including their home directory, PATH, and shell configuration files. Without the hyphen, you switch users but keep your current environment, which can lead to unexpected behavior where commands don't work as expected.
Both sudo and su have their place in Linux system administration, but for most tasks, sudo is the better choice. It's more secure, provides accountability through logging, and follows modern security best practices by limiting elevated privileges to only when they're needed.
If you're managing servers, especially in a team environment, configuring sudo properly should be part of your initial setup process. It makes your infrastructure more secure while still giving administrators the access they need to do their jobs.
Thanks for reading! If you're looking for infrastructure to host your Linux projects, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered KVM VPS hosting. For shared hosting needs, check out our San Jose shared hosting plans. We also offer IP transit and a full range of IT services.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.