Managing Linux Users, Groups, and Permissions on a Production Web Server

Operating a Linux server securely begins with strict user separation. Using the root account for daily development and deployment tasks exposes the operating system to accidental file deletions, compromised background processes, and privilege escalation vulnerabilities. A clean multi-user setup limits damage by enforcing least-privilege access.

NOTE: The VPS used here is from interserver.net at a price of $ 3 per month. Click here to purchase, or text us, and we will guide you

1. Creating Standard and System Users

When provisioning a server, create standard user accounts for team members or automated deployments rather than sharing root credentials:

sudo adduser developer_john

This command prompts for a password and automatically provisions a home directory at /home/developer_john/ with balanced file permissions.

2. Granting Administrative Sudo Access

Rather than logging in as root, add trusted engineers to the sudo group. Members of this group can run administrative commands while creating an audit trail in system logs:

sudo usermod -aG sudo developer_john

To revoke administrative capabilities while keeping the user account active, remove them from the group:

sudo deluser developer_john sudo

3. Understanding User Groups for Web Services

Web servers like Nginx run under system accounts such as www-data. When your application files belong to a deploy user, you can share read access without granting full write permissions across the entire operating system by using shared groups.

To add the web server to the deploy group:

sudo usermod -aG deploy www-data

To view all groups an account currently belongs to, run:

groups developer_john

4. Managing File and Directory Permissions

Linux permissions are governed by three octal digits representing user, group, and others:

• Read (4): Allows viewing file contents or listing directory items.
• Write (2): Allows modifying file data or adding/removing directory entries.
• Execute (1): Allows running programs or traversing directory hierarchies.

For a web application directory, standard production permissions look like this:

sudo chown -R deploy:www-data /home/deploy/Projects/myapp.com
sudo find /home/deploy/Projects/myapp.com -type d -exec chmod 755 {} \;
sudo find /home/deploy/Projects/myapp.com -type f -exec chmod 644 {} \;

This ensures the owner can edit files, while the group (and others) can only read them and enter directories without permission to overwrite or inject arbitrary code.

5. Locking Down SSH and Disabling Direct Root Logins

Once you verify that your non-root user can log in and execute sudo commands, lock down SSH authentication. Open the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Find and update these directives to eliminate automated brute-force attacks against your root user:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Restart the SSH daemon to apply changes:

sudo systemctl restart ssh

6. Deactivating or Removing Stale Users

When an engineer leaves a project or an account is no longer needed, remove access immediately. To temporarily lock an account without deleting their data:

sudo passwd -l developer_john

To unlock the account later:

sudo passwd -u developer_john

To completely delete a user along with their home directory and mailbox:

sudo deluser --remove-home developer_john

Regular user audits and strict group boundaries protect production servers from unauthorized access and ensure steady operational hygiene.