Furkan İkkan Türkçe
Back to posts
Post

· Network & System Administrator

Linux System Administration Without Root: Least Privilege With Sudo

Manage Linux systems without giving root access. Learn sudoers configuration, command restrictions, and least privilege practices for secure sysadmin work.

Linuxsudoleast privilegesystem administrationsudoerssecuritysysadmin

Linux system administration without root access is entirely possible when you configure sudo properly and follow the principle of least privilege. In my environment, I never hand out the root password or let anyone log in as root directly. Instead, I grant specific users permission to run only the commands they actually need, with full logging attached. Here's how I do it.

As I mentioned before when comparing OS choices (https://furkanikkan.com/urun/linux-mu-windows-server-mi-gercek-senaryolara-gore-dogru-os-secimi-39), Linux gives you fine-grained control over permissions — but only if you actually use it. The default sudo ALL=(ALL:ALL) ALL grant is convenient and terrible for security.

Why You Should Disable Direct Root Login

The first step is making sure nobody can SSH in as root. This forces everyone through sudo, which means every privileged action hits the logs with a real username attached.

Edit /etc/ssh/sshd_config and set:

PermitRootLogin no

Then restart the SSH daemon:

systemctl restart sshd

Now every administrative action is traceable to a person, not a shared root account that ten people use and nobody admits to.

Sudoers Configuration: The Right Way

The biggest mistake I see is admins editing /etc/sudoers directly. Don't. One syntax error and you lock yourself out of privilege escalation entirely. Always use visudo:

visudo -f /etc/sudoers.d/webops

Using files in /etc/sudoers.d/ keeps things modular. You can assign one file per team or application and remove access by deleting a single file instead of hunting through a 200-line config.

Here's a real example from my environment. The web operations team needs to restart nginx and reload PHP-FPM, but nothing else:

Cmnd_Alias WEBOPS = /bin/systemctl restart nginx, /bin/systemctl reload nginx, /bin/systemctl restart php-fpm

%webops ALL=(ALL) WEBOPS

That group can now run exactly those three commands with root privileges. They can't install packages, edit sudoers, or touch anything else.

Practical Least Privilege Examples

Here are the restriction patterns I use most often:

  • Backup operators: Allow rsync and tar to specific paths, nothing else
  • Database team: Allow systemctl restart postgresql and psql as the postgres user, but not general root
  • Monitoring user: Allow reading specific log files and running systemctl status on monitored services
  • Deploy user: Allow restarting the app service and clearing the cache directory, no package management

A database admin example:

dbadmin ALL=(postgres) /usr/bin/psql, /bin/systemctl restart postgresql

Notice the (postgres) part — that user can run commands as the postgres system user, not as root. That's a huge difference. If someone compromises that account, they get database-level access, not full system control.

Sudo Logging and Auditing

Without logging, least privilege is just a suggestion. Sudo logs to /var/log/auth.log on Debian-based systems and /var/log/secure on RHEL-based systems by default. Check it:

grep sudo /var/log/auth.log | tail -20

You'll see every command run, who ran it, and from where. If you're managing multiple servers, ship these logs to a central syslog server or SIEM. In my setup, I forward sudo logs to a central rsyslog collector so I can search across all machines at once.

If you want even tighter auditing, add this to your sudoers file:

Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io

This records the full input and output of every sudo session. It's verbose, but when something breaks at 3 AM, you'll be grateful you can replay exactly what happened.

Common Pitfalls to Avoid

I've seen these mistakes break least privilege setups more than once:

  1. Wildcard commands: Writing /bin/systemctl * in sudoers looks safe but lets users restart any service, including shutting down the machine. Be explicit.
  2. Forgetting shell escapes: If you let someone run vim or less as root, they can spawn a shell from inside those programs and get full root access. Use NOEXEC or avoid granting interactive tools.
  3. Group drift: You grant access to a group, people leave the team, and nobody removes them from the group. Audit group membership regularly.
  4. NOPASSWD everywhere: Passwordless sudo is convenient for automation but dangerous for interactive users. Reserve it for specific service accounts only.

A safer way to handle automation accounts:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /usr/local/bin/clear-cache.sh

Locked to two commands, no password needed, no shell escape possible.

Testing Your Sudoers Setup

Before you close your session, test the new configuration. Run sudo -l as the restricted user to see exactly what they can do:

sudo -l -U webops_user

And verify the syntax of your sudoers file:

visudo -c

If that returns a parse error, fix it before anyone relies on it. I always keep a root shell open in a separate terminal when editing sudoers, just in case.

Wrapping Up

Least privilege on Linux isn't hard, but it requires discipline. Disable root login, use visudo, create modular sudoers files, log everything, and test before you trust. The five minutes you spend writing a precise sudoers rule saves you from the 3 AM incident where someone ran rm -rf as root because they had ALL access they didn't need.

In my environment, every new server gets this treatment before it goes into production. No exceptions.

Cover image: personalgraphic.official · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/198895458@N04/53097628210