When you su to root, you're elevating privileges from a standard user account, whereas direct root login means operating with maximum privileges from the very beginning. This creates different security implications:

# Direct root login (risky)
$ ssh root@server

# Safer privilege elevation
$ ssh user@server
$ su -
Password: 

Using su maintains better accountability through system logs. Each privilege escalation creates an audit trail showing which user account performed the action:

# Sample auth.log entries
May 15 10:23:01 server su[1234]: pam_unix(su:session): session opened for user root by alice(uid=1000)
May 15 10:25:43 server sshd[5678]: Accepted password for root from 192.168.1.10 port 4242

Direct root logins expose your system to brute force attacks. Most security-conscious sysadmins disable root login via SSH entirely:

# /etc/ssh/sshd_config
PermitRootLogin no

Working as a standard user by default prevents accidental system-wide changes. When you need root privileges, the explicit su action serves as a conscious security checkpoint.

Here's how to properly configure a multi-user system with controlled root access:

# Create admin user
useradd -m -G wheel adminuser
passwd adminuser

# Configure sudo (better than su)
visudo
# Uncomment: %wheel ALL=(ALL) ALL

# Then admin users can:
sudo -i
# Instead of:
su -

Modern practices recommend sudo over su for finer-grained control:

# Granular sudo permissions example
%webadmins ALL=(root) /usr/bin/systemctl restart nginx
%dbadmins ALL=(postgres) /usr/bin/psql

Logging in directly as root creates unnecessary security risks. When you su to root, you leave an audit trail showing which regular user escalated privileges. Direct root logins make it harder to track who performed sensitive operations.

# Bad practice - direct root login
$ ssh root@server

# Better approach - privilege escalation
$ ssh admin@server
$ su -
Password: ********

The second method forces you to authenticate twice and maintains accountability through the original user session.

Modern systems prefer sudo over su for even better security:

# Configure sudo access in /etc/sudoers
admin ALL=(ALL) ALL

# Then users can run commands with:
$ sudo apt update

Here's how to properly set up a production server:

# 1. Create admin user
adduser deployer
usermod -aG sudo deployer

# 2. Disable root SSH login
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart sshd

# 3. Require sudo for root access
echo "%sudo ALL=(ALL:ALL) ALL" >> /etc/sudoers

With proper logging configured, you can track privilege escalations:

# View sudo history
sudo cat /var/log/auth.log | grep sudo

# Sample output:
Jun 15 10:23:45 server sudo: deployer : TTY=pts/0 ; USER=root ; COMMAND=/usr/bin/apt update

In rare cases like single-user mode recovery, direct root access becomes necessary:

# Boot into single-user mode
# At GRUB: add 'single' to kernel parameters
# Then you'll have direct root shell