What is the difference between sudo and su for routine server administration?

Why sudo and su differ in day-to-day administration

The practical difference is about scope and control. sudo grants privilege for one command, or a narrowly defined administrative action, so routine work stays in your normal user context unless escalation is needed. su changes you into the root account itself, which makes the privileged context persistent until you exit. That difference matters most on shared, audited, or production systems.

sudo is usually the better fit when administration is occasional, task-specific, and tied to accountability. It lets you separate everyday activity from privileged actions, reduce accidental root use, and record who ran what. su can still be useful for maintenance or legacy workflows, but it places more responsibility on the operator to manage the session carefully.

How the security model changes with each command

With sudo, the security boundary is the command and the policy behind it. Administrators can limit which users may run which commands, whether a password is required, and whether elevation is temporary. That supports tighter least-privilege administration and makes it easier to delegate narrow tasks without handing out full root access.

With su, the boundary is the account switch itself. Once you are root, every subsequent command in that shell runs with full superuser authority until the session ends. That broader context is simple, but it increases the chance that an operator will perform an unrelated action with elevated rights or forget they are still in a privileged shell.

On a well-managed system, sudo also improves attribution because individual privileged actions are easier to tie back to a named user and a specific command path. For routine administration, that traceability is often more valuable than convenience.

When routine server work becomes risky

The risk is not that su is inherently broken, but that it expands the blast radius of human error. A persistent root shell makes it easier to edit the wrong file, run the wrong cleanup command, or reuse a privileged session longer than intended. On multi-admin systems, that can create avoidable exposure because a shared privileged context is harder to constrain and review.

Failure mechanism: Broad root context increases the chance of unintended privileged actions, and it weakens separation between ordinary work and administration. If the operator’s session is already root, a mistake that would have been harmless under a standard account can become a system-wide change.

Impact: The result can be configuration drift, service disruption, or easier abuse of administrative access if a workstation or terminal session is compromised while root is still active. For that reason, many teams prefer sudo plus tightly scoped policy over habitual su use for everyday administration.

Practitioner Guidance

What to verify: Make sure administrative tasks can be completed with narrowly scoped privilege rather than a permanent root shell. If a task needs repeated elevation, check whether the command set can be reduced and delegated more safely instead of defaulting to full root context.

Decision rule: If the work is a single action, prefer sudo; if you need a root shell for a documented maintenance procedure, keep the session short and exit immediately after the task. Treat long-lived privileged shells as an exception, not the normal operating mode.

What good looks like: Ordinary user activity stays in an unprivileged account, privileged actions are deliberate and logged, and administrators can explain why root was needed for each elevated task. That is the operational pattern that reduces routine misuse without slowing legitimate work.

Practitioner takeaway: For routine server administration, the key distinction is not syntax but blast radius, sudo constrains privilege to the task, while su makes privilege the default for the whole session.

Related resources from NHI Mgmt Group

• What breaks when privileged administration is not separated from routine work?
• How should security teams restrict access to identity server administration planes?
• How should teams use PowerShell to automate routine Active Directory access administration without increasing operational risk?
• How should IT teams manage Linux user access across hybrid environments without relying on per-server manual administration?