Restricting User Access

Restricting what users can do after they log in is as important as controlling who can log in. Ubuntu provides several tools: time-based restrictions via PAM, SSH config for network access control, chroot jails to confine users to a directory, and restricted shells for limiting available commands. Most production environments use a combination of these layers.

Time-based access restrictions

The pam_time module restricts login times. For example, a contractor account that should only be usable during business hours:

# Install and configure time-based restrictions
# Edit /etc/security/time.conf
sudo nano /etc/security/time.conf

/etc/security/time.conf syntax

# Format: services;ttys;users;times
# Services: sshd, login, su
# ttys: * (all terminals), tty1, pts/*
# Users: user1|user2, !user (not user)
# Times: Day HH:MM-HH:MM (Mo Tu We Th Fr Sa Su Al Wk Wd)

# Allow contractor only on weekdays 8am-6pm
sshd;*;contractor;Wk0800-1800

# Allow devs any time Mon-Fri, only 9-5 on Saturday
sshd;*;dev1|dev2;Al0000-2400&Wk0000-2400|Sa0900-1700
# Enable pam_time in /etc/pam.d/sshd
# Add this line near the top (before other auth lines):
sudo nano /etc/pam.d/sshd
# Add: account  required  pam_time.so

Restricting which users can use SSH

# Edit SSH daemon configuration
sudo nano /etc/ssh/sshd_config

Restricting SSH access to specific users or groups

# Allow only specific users
AllowUsers irfan deploy ansible

# Allow only specific groups (members of these groups can SSH)
AllowGroups sshusers admins

# Deny specific users (even if they are in AllowGroups)
DenyUsers baduser former-employee

# Deny specific groups
DenyGroups contractors
# Apply the change
sudo systemctl reload sshd

# Test the new configuration before reloading (avoids lockout)
sudo sshd -t && sudo systemctl reload sshd

⚠️ WARNING: Always test SSH configuration changes in a second terminal before closing your current SSH session. If you lock yourself out with an incorrect AllowUsers directive, you will need console access to fix it. Keep an emergency access method (cloud provider console, IPMI, physical access) available before making SSH changes.

chroot jail for SFTP users

A chroot jail restricts a user to a specific directory — they cannot navigate above it. This is commonly used for SFTP-only users who need to upload files but should not have full shell access.

# Create the chroot jail directory structure
sudo mkdir -p /srv/sftp-jail/uploads

# chroot root must be owned by root (this is an SSH security requirement)
sudo chown root:root /srv/sftp-jail
sudo chmod 755 /srv/sftp-jail

# The upload directory is owned by the user
sudo chown irfan:irfan /srv/sftp-jail/uploads
sudo chmod 755 /srv/sftp-jail/uploads

# Configure SSH for chroot SFTP
sudo nano /etc/ssh/sshd_config

sshd_config additions for chroot SFTP

Match User irfan
    ChrootDirectory /srv/sftp-jail
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
sudo systemctl restart sshd

# Test: the user should only see /uploads inside the jail
sftp irfan@server
# Inside sftp:
pwd    # Should return: /
ls     # Should see only: uploads

Restricting commands with rbash

# rbash (restricted bash) prevents users from:
# - Changing directories
# - Modifying PATH
# - Redirecting output
# - Running commands with /

# Set a user's shell to rbash
sudo usermod -s /bin/rbash irfan

# Create a restricted PATH with only allowed commands
sudo mkdir -p /home/irfan/bin
sudo chown root:root /home/irfan/bin    # Prevent user from modifying it
sudo chmod 755 /home/irfan/bin

# Symlink only allowed commands
sudo ln -s /usr/bin/ls /home/irfan/bin/ls
sudo ln -s /usr/bin/cat /home/irfan/bin/cat

# Set restrictive .bash_profile (owned by root, user cannot modify)
echo 'export PATH=/home/irfan/bin' | sudo tee /home/irfan/.bash_profile
sudo chown root:irfan /home/irfan/.bash_profile
sudo chmod 644 /home/irfan/.bash_profile

PAM-based access restrictions

# /etc/security/access.conf — control login access by user/group/host
sudo nano /etc/security/access.conf

/etc/security/access.conf examples

# Format: permission : users : origins (tty/host)
# + = allow, - = deny

# Allow only admins group to log in from any origin
+ : (admins) : ALL

# Allow irfan from specific IP range
+ : irfan : 192.168.1.0/24

# Deny everyone else
- : ALL : ALL
# Enable pam_access in /etc/pam.d/sshd
# Add: account  required  pam_access.so

Conclusion

Layer access restrictions: use SSH AllowUsers/AllowGroups to control who can connect via SSH, use pam_time for time-based restrictions, use chroot jails for SFTP-only file upload accounts, and use rbash for users who need a highly limited command-line environment. Each layer independently enforces a restriction, so multiple layers ensure that bypassing one does not immediately give full access.

FAQ

Is Restricting User Access important for Ubuntu administrators?+

Yes. It supports practical Ubuntu administration because it connects directly to server reliability, security, troubleshooting, or daily operations.

Should I practice this on a live server?+

Use a lab VM first. After you understand the command output and rollback path, apply the workflow carefully on real systems.

What should I do after reading this article?+

Run the practice commands, write down what each one shows, and continue to the next article in the Ubuntu roadmap.

Need help with Ubuntu administration?

Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.

Hire Me for Support