Linux User Management Guide

📚 What You'll Master Today

By the end of this guide, you'll confidently:

• Understand why running as root 24/7 is a security nightmare
• Create operational users with proper permissions
• Set up password less SSH authentication
• Manage user groups and access control
• Follow production-ready security practices

🤔 Why This Matters (The Root Problem)

The Rookie Mistake

Picture this: You just got your first VPS. You SSH in as root and start installing everything. Docker? Check. PostgreSQL? Check. Accidentally deleted your entire production database with one mistyped command? Check. 😱

The Root Reality

Running as root means:

• ❌ No safety net—every command runs with supreme power
• ❌ No audit trail—can't track who did what
• ❌ Security nightmare—one compromised session = full server access
• ❌ Industry taboo—no professional runs production servers this way

Running with dedicated users means:

• ✅ Commands require explicit sudo approval
• ✅ Clear audit logs of all privileged actions
• ✅ Isolated permissions per service
• ✅ Sleep peacefully knowing accidents won't destroy everything

Real-World Scenario

Imagine you're managing a server with multiple services:

• Bad approach: Everything runs as root

  • Odoo crashes? Might have access to your entire system
  • Team member needs access? Give them root (yikes!)
  • Something breaks? Good luck finding who did it

• Pro approach: Dedicated users for each purpose

  • devops user for daily operations
  • odoo user runs your application
  • deploy user handles CI/CD
  • Everything logged, isolated, and secure

🏗️ Understanding Linux User Types

Think of your server like a building with different access levels:

🏢 Your VPS Server
  ├── 👑 Root (0)
  │   └── The building owner—can do anything
  │
  ├── ⚙️ System Users (1-999)
  │   └── Service accounts (nginx, postgres, docker)
  │
  └── 👤 Regular Users (1000+)
      └── Human operators (devops, admin, you!)

Key Insight: System users run services. Regular users operate the server. Root is for emergencies only.

🛠️ Prerequisites: Your Toolkit

Required:

• A Linux VPS (Ubuntu 22.04 LTS recommended)
• SSH access to your server
• 10 minutes of focused time

Optional but Recommended:

• PowerShell/Terminal on your local machine
• Basic command line familiarity

🚀 Quick Start: Creating Your Operational User

Step 1: Connect as Root (Last Time!)

# From your local machine
ssh root@your-server-ip

Step 2: Create Your DevOps User

# Create a system user with bash shell
sudo useradd --system --shell /bin/bash --create-home devops

# Add to docker group (if you use Docker)
sudo usermod -aG docker devops

# Grant sudo privileges (no password required for convenience)
echo "devops ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/devops
sudo chmod 440 /etc/sudoers.d/devops

# Verify setup
id devops

Expected output:

uid=999(devops) gid=999(devops) groups=999(devops),998(docker)

Step 3: Set Up Passwordless SSH Access

On your local machine (PowerShell/Terminal):

# Generate SSH key pair
ssh-keygen -t ed25519 -C "devops@your-server" -f ~/.ssh/devops_key

# Copy public key to clipboard
# Windows PowerShell:
Get-Content ~/.ssh/devops_key.pub | Set-Clipboard

# Mac/Linux:
cat ~/.ssh/devops_key.pub | pbcopy

Back on your server (as root):

# Create SSH directory for devops user
sudo mkdir -p /home/devops/.ssh
sudo chmod 700 /home/devops/.ssh

# Add your public key (paste the key you copied)
sudo nano /home/devops/.ssh/authorized_keys
# Paste your public key, save (Ctrl+X, Y, Enter)

# Set proper permissions
sudo chmod 600 /home/devops/.ssh/authorized_keys
sudo chown -R devops:devops /home/devops/.ssh

Step 4: Configure SSH Shortcut

On your local machine, edit ~/.ssh/config:

Host myserver
  HostName your-server-ip
  User devops
  IdentityFile ~/.ssh/devops_key
  Port 22

Now connect with one command:

ssh myserver

✨ You're in! No password needed. Professional-grade security achieved.

📋 Essential User Management Commands

User Operations

# Create regular user
sudo adduser username

# Create system user (for services)
sudo adduser --system --home=/opt/appname appuser

# Delete user (keep home directory)
sudo deluser username

# Delete user and home directory
sudo deluser --remove-home username

# Modify user shell
sudo usermod -s /bin/bash username

# Lock/unlock user account
sudo usermod -L username  # Lock
sudo usermod -U username  # Unlock

Group Management

# Create group
sudo addgroup developers

# Add user to group (recommended way)
sudo usermod -aG groupname username

# Remove user from group
sudo gpasswd -d username groupname

# View user's groups
groups username

# View group members
getent group groupname

Quick Checks

# Who am I?
whoami

# What groups do I belong to?
groups

# See all users
cut -d: -f1 /etc/passwd | head -20

# Check user details
id username

🔒 Production Security Checklist

Immediate Actions

1. Disable root SSH login:

sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

2. Disable password authentication:

sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

3. Install fail2ban (brute force protection):

sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable fail2ban

Monthly Maintenance

# Audit sudo access
getent group sudo

# Check for users with bash shells
grep '/bin/bash' /etc/passwd

# Monitor recent logins
last -n 20

# Check failed login attempts
sudo grep "Failed password" /var/log/auth.log | tail -20

🎯 Common Scenarios & Solutions

Scenario 1: Need to give team member access?

# Create user account
sudo adduser teammate

# Add to necessary groups
sudo usermod -aG docker,sudo teammate

# They send you their public key, you add it
sudo mkdir -p /home/teammate/.ssh
echo "their-public-key-here" | sudo tee /home/teammate/.ssh/authorized_keys
sudo chmod 600 /home/teammate/.ssh/authorized_keys
sudo chown -R teammate:teammate /home/teammate/.ssh

Scenario 2: Service needs its own user?

# Create system user for your app
sudo adduser --system --group --home=/opt/myapp myapp

# Set ownership of app directory
sudo chown -R myapp:myapp /opt/myapp

Scenario 3: Messed up permissions?

# Reset home directory permissions
sudo chown -R username:username /home/username
sudo chmod 755 /home/username
sudo chmod 700 /home/username/.ssh
sudo chmod 600 /home/username/.ssh/authorized_keys

🚨 Troubleshooting

"Permission denied (publickey)"

# On server, check SSH key permissions
ls -la /home/devops/.ssh/
# Should show:
# drwx------ .ssh
# -rw------- authorized_keys

# Fix if needed
sudo chmod 700 /home/devops/.ssh
sudo chmod 600 /home/devops/.ssh/authorized_keys

"User is currently used by process"

# Find processes owned by user
ps aux | grep username

# Stop the process
sudo kill -9 process_id

# Now try deleting user again
sudo deluser username

Locked out of server?

Prevention is key:

• Always keep one root session open while testing
• Test new user login in a separate terminal before closing root session
• Have backup access method (VPS console in provider's dashboard)

📊 Quick Reference Cheat Sheet

🎓 Key Takeaways

1. Never run as root for daily operations — Create dedicated users
2. Use SSH keys, not passwords — More secure, more convenient
3. Follow least privilege principle — Grant minimum necessary permissions
4. Audit regularly — Know who has access to what
5. Document everything — Future you will thank present you

💡 Final Thought

User management isn't just about security—it's about building sustainable infrastructure. A well-managed server is:

• Secure by design
• Auditable when things go wrong
• Scalable as your team grows
• Professional in every aspect

Welcome to the ranks of professional Linux administrators! 🎉