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