How to restrict SSH user access to home directory on Linux?

You can secure your linux environment by combining filesystem rules with strict account isolation. You configure ssh user access to restrict user access to a single home directory. System administrators implement a chroot jail to stop lateral directory traversal across sensitive server locations.
You must also enforce strong POSIX permissions on parent folders to prevent unauthorized file browsing. Effective directory isolation requires three clear prerequisites before you edit configuration files. You need root privileges on the host server, an active OpenSSH daemon running, and a standard account for testing. These basic administrative requirements ensure safe security deployment without locking yourself out of the remote system.
Configure SSH Chroot Jail Environment
You configure ssh settings to isolate accounts inside a secure chroot jail. System administrators restrict a user to a specific directory to block unauthorized system traversal across critical server paths.
Apply SSH Chroot Directives in sshd_config
You edit /etc/ssh/sshd_config when you create chroot jail configurations for target accounts. OpenSSH evaluates parameters based on individual account or group definitions. The following table highlights the operational differences between matching criteria:
| Observation | Match User with ChrootDirectory | Match Group directive added alongside |
|---|---|---|
| Config reprocessing | The user is resolved normally; debug logs show a valid username in user test matched group list .... | Group matching is attempted with an empty username, producing Can't match group ... because user does not exist. |
| ChrootDirectory behavior | The ChrootDirectory is applied reliably, e.g. to C:\, and the SFTP session is jailed correctly. | The ChrootDirectory is not applied consistently because config reprocessing fails before the user is fully re-resolved. |
| Connection outcome | Successful SFTP session; pwd and directory listing work. | Intermittent Permission denied or client_loop: send disconnect: Connection reset; failures can vary between attempts. |
You append directives at the end of /etc/ssh/sshd_config to enforce session isolation:
Subsystem sftp internal-sftp
Match Group sftpgroup
ChrootDirectory /sftp/%u
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding noSet Up Chroot Directory Ownership
Strict ownership rules govern every isolated environment on Linux. OpenSSH validates all parent directories prior to granting access:
sshd verifies that every component of the chroot path is owned by root and cannot be written to by any other user or group. After authentication, it chroots to that directory and then changes to the user’s home directory.
You follow sequential deployment steps to create and configure ssh user access safely:
- Create a dedicated group using
groupadd sftpgroup. - Create a chroot root directory with
mkdir /sftp, then set ownership withchown root:root /sftpand permissions withchmod 755 /sftp. - Execute
useradd -g sftpgroup -s /sbin/nologin sftpuserto add an account without shell access, then set a password usingpasswd sftpuser. - Create an upload folder inside the environment using
mkdir /sftp/sftpuser/upload, then set access withchown root:root /sftp/sftpuserandchmod 777 /sftp/sftpuser/upload. - Restart the daemon using
systemctl restart sshd.service.
You must execute precise command sequences when managing accounts during setup:
- Run
useraddduring initial account creation to assign baseline attributes. - Use
usermod -d /sftp/sftpuser/upload sftpuserto modify existing directory paths. - Apply
usermod -s /sbin/nologin sftpuserto disable shell interactive access. - Execute
usermod -aG sftpgroup sftpuserto place an existing user inside the group. - Keep root ownership on parent folders or the chroot process fails completely.
This common jail chroot configuration confines file transfers while blocking filesystem navigation. If you use key authentication, set AuthorizedKeysFile /home/%u/.ssh/authorized_keys because key verification occurs before entering the chroot environment. Providing a writable folder inside the jail allows file transfers while keeping the jail secure.
Restrict User Access via POSIX Permissions
Default linux configurations often allow non-root accounts to view folder names inside shared system locations. Unprivileged accounts can list contents across parent paths without authorization. You must adjust system configuration settings to restrict user access completely. You restrict user access to keep confidential data safe.
System administrators modify POSIX rules to secure the primary home directory path. You configure strict access rights to prevent unauthorized browsing across user locations.
Harden Parent Home Directory Access
Standard linux installations let accounts view directory structures under shared parent paths. You secure these locations by altering navigation controls at the main system level.
Administrators apply explicit command options to control directory entry and file listing operations:
chmod 750 /home: Grants complete control to the owner, read and execute rights to group members, and zero access rights to outside accounts.chmod 711 /home: Grants execution access to all accounts so individuals traverse through home without viewing listed directory contents.
These settings stop unprivileged accounts from mapping host folder structures while preserving normal path traversal for legitimate user accounts.
Secure the User’s Home Directory Permissions
You must lock down individual folder settings after securing the primary parent location. Setting chmod 700 on a user’s home directory grants read, write, and execute rights exclusively to the owner. This mode blocks group members and external accounts from viewing private files.
OpenSSH checks filesystem security during active authentication attempts. The remote SSH service rejects connections when target account folders use loose modes.
| Mode | Owner | Group | Others | Security Implication |
|---|---|---|---|---|
| 700 | Read, Write, Execute | None | None | Locks access exclusively to the target user. |
| 755 | Read, Write, Execute | Read, Execute | Read, Execute | Allows external accounts to read files inside the home directory. |
You maintain strong account isolation across your host by applying mode 700 directly to each individual user’s home directory.
Implement Restricted Shells and Commands
You can deploy a restricted shell to restrict a user beyond basic system configurations. A restricted shell locks down execution privileges and stops accounts from leaving designated locations.
Configure Restricted Bash Shell Environment
System administrators use a restricted shell to block unauthorized command execution over SSH sessions. You first confirm rbash exists on your system. You create a symbolic link from /usr/bin/bash to /usr/bin/rbash if your system lacks the default binary.
Next, you register a new account using useradd or update an existing profile. You assign rbash during account setup with useradd -s /usr/bin/rbash newuser. You modify an existing target account using usermod -s /usr/bin/rbash targetuser. You can execute usermod again whenever you need to update shell assignments. If you migrate accounts, you invoke usermod to adjust profile settings. System administrators run usermod to maintain shell boundaries across all managed accounts.
Limit Binaries in Custom Command Paths
You enforce path isolation to prevent execution of unauthorized binaries. You create a root-owned folder inside the user home path like /home/targetuser/.bin to serve as a specific directory for safe binaries. You link only approved commands into this directory, such as ls, su, and clear.
In the profile .bashrc file, you define PATH=$HOME/.bin and set umask 077. You change file ownership to root:targetuser so accounts cannot alter startup scripts.
The following table summarizes the built-in safeguards enforced by a restricted shell:
| rbash restriction | What it prevents | Observed evidence |
|---|---|---|
cd disabled | Changing the working directory | cd /tmp fails with a “restricted” error |
exec, set, unset blocked | Shell environment changes and new shell sessions | exec bash fails with a “restricted” error |
| Redirection disabled | Writing or reading files via >, <, >> | echo "Test" > test.txt is rejected |
Pathnames with / rejected | Launching commands by absolute/relative path outside PATH | Trying /bin/ls is rejected with a “restricted” error |
PATH set to a specific user bin | Executing arbitrary commands outside the allowed set | Only whitelisted scripts like hello.sh run |
| SSH one-off command | Not prevented by rbash interactive-mode restrictions | A comment notes ssh some_host any_command still works |
Using a restricted shell stops users from launching unapproved programs, executing directory changes, or modifying critical environment variables.
Validate User Isolation and Access Limits
Test SFTP and Shell Boundary Controls
You perform an active sftp check with chroot jail parameters after updating your server configuration. This test confirms that remote accounts stay locked inside designated boundary locations. You open a terminal and execute sftp user@host via ssh to test file transfer constraints under active connections. The server restricts entry immediately upon login. Setting ForceCommand internal-sftp in /etc/ssh/sshd_config restricts session capability entirely to file management. You apply strict rules to restrict user access across all system locations.
Next, you evaluate interactive session restrictions. You test system security by launching ssh user@host to start a session. A restricted shell blocks commands that alter working locations. You run shell built-in commands like pwd, echo, and history successfully because bash processes them internally. However, external binaries like ls, date, or uname fail completely when you lock down the user’s home directory path. A proper restricted shell denies attempts to execute outside binaries or change environment paths. Proper chroot jail settings keep accounts isolated.
Verify SSH User Access and Traversal Limits
You verify ssh user access limits by testing directory navigation controls directly. Follow these steps to validate your chroot jail implementation:
- Log in as the jailed user:
ssh jailuser@localhost. - At the remote shell, change to the apparent root:
cd /. - List the directory with
ls; only jail contents should be visible, not the real filesystem. - Attempt to move up with
cd ..; the session should remain at/, proving directory traversal is blocked. - Verify chroot activation in the audit log:
sudo grep -i chroot /var/log/auth.log.
This structured testing routine confirms that system boundaries restrict user access effectively across remote sessions.
Testing ensures your chroot jail configuration isolates accounts without unexpected access leaks.
You verify your isolated environment by executing active test commands. Run ssh user@host to establish a new remote session. Next, execute pwd and attempt directory navigation using cd ... The active session locks your path inside the target directory structure. You must conduct regular security audits on directory permissions across your linux host to prevent privilege regression and keep access rights secure.
You monitor system logs to catch unauthorized access attempts early. Inspect /var/log/auth.log or run journalctl -u ssh on your server. These system logs display login authentication details and record failed traversal events immediately. Continuous log checking maintains effective user account boundary controls across your server environment over time.
FAQ
Why does ssh fail when you set wrong permissions on a chroot jail?
OpenSSH enforces strict security standards. Root must own every parent directory in the path before launching a chroot jail. Group write permissions break these security checks. Consequently, your connection fails or skips environment setup.
How do you restrict an account to a jail without shell access?
You set the account shell to /sbin/nologin. Next, you assign ForceCommand internal-sftp in your configuration file. This setting confines remote file transfers inside the designated jail.
Can accounts escape their home folder in a linux environment?
No, a restricted shell blocks navigation builtins like cd. The system denies path modifications and command execution outside allowed paths. Users cannot escape their target folder or alter system variables.
What permissions block users from viewing other home folders?
You apply chmod 700 on each personal directory. This command grants full access rights exclusively to the owner. Additionally, you set chmod 750 on /home to prevent unprivileged accounts from reading parent paths.
How do you confirm that chroot isolates an ssh session?
You establish a session using ssh to test boundary limits. You execute cd .. to check traversal restrictions. The active session locks your path inside the second jail, while system logs confirm proper chroot activation.
