Practical Server Security: Root Access, SSH, and Containers

This document summarizes pragmatic security best practices for self-hosted servers, especially in containerized environments.

---

🔐 Root Login and SSH

✅ Recommended SSH Configuration

Edit /etc/ssh/sshd_config to include:

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

Then restart SSH:

sudo systemctl restart sshd

What PermitRootLogin prohibit-password Means

• SSH access as root:
  • ❌ Password login → disabled
  • ✅ SSH key login → allowed
• Local access as root:
  • ✅ Still allowed (keyboard/direct console, su, sudo)

Scenario	Allowed?
SSH with root password	❌
SSH with root key	✅
Local login as root (physical)	✅
su - or sudo from another user	✅

---

🧱 Containers and Root Access

• Some services (e.g., MariaDB, PostgreSQL) expect to run as root or a dedicated system user.
• It's OK for a container process to run as root inside the container, but not ideal to mount host directories with root-level access without control.

Tips:

• Use Docker --user where possible.
• Prefer non-root base images (e.g., Alpine with USER appuser).
• Manage sensitive volumes with strict permissions.

---

🔒 General Best Practices

Area	Best Practice
SSH Keys	Use only keys, disable passwords
Root over SSH	Permit only with key, or disable entirely
Sudo Access	Use per-user control with sudoers
Firewall	Use ufw, iptables, or host firewall
SSH Port	Optional: change from 22 to obscure scans
Fail2Ban	Block brute-force attempts
Automatic Updates	Enable unattended security upgrades
Docker	Limit --privileged, avoid mounting sensitive host paths
Backup	Encrypted, offsite, and tested

---

🚀 Conclusion

Pragmatic security balances protection with usability. For self-hosted environments:

• Root via SSH with keys only is acceptable.
• Local root access remains essential for recovery.
• Containers can run as root internally if isolated properly.