How to Restrict SFTP Users to Home Directories Using chroot Jail

In this tutorial, we will be discussing how to restrict SFTP users to their home directories or specific directories. It means the user can only access his/her respective home directory, not the entire file system.

Restricting users home directories is vital, especially in a shared server environment, so that an unauthorized user won’t sneak peek into the other user’s files and folders.

Important: Please also note that the purpose of this article is to provide SFTP access only, not SSH logins, by following this article will have the permissions to do file transfer, but not allowed to do a remote SSH session.

Suggested Read: Restrict SSH User Access to Certain Directory Using Chrooted Jail

The simplest way to do this, is to create a chrooted jail environment for SFTP access. This method is same for all Unix/Linux operating systems. Using chrooted environment, we can restrict users either to their home directory or to a specific directory.

Restrict Users to Home Directories

In this section, we will create new group called sftpgroup and assign correct ownership and permissions to user accounts. There are two choices to restrict users to home or specific directories, we will see both way in this article.

Create or Modify Users and Groups

Let us restrict the existing user, for example tecmint, to his/her home directory named /home/tecmint. For this, you need to create a new sftpgroup group using groupadd command as shown:

# groupadd sftpgroup

Next, assign the user ‘tecmint’ to sftpgroup group.

# usermod -G sftpgroup tecmint

You can also create a new user using useradd command, for example senthil and assign the user to sftpusers group.

# adduser senthil -g sftpgroup -s /sbin/nologin
# passwd tecmint

Modify SSH Configuration File

Open and add the following lines to /etc/ssh/sshd_config configuration file.

Subsystem sftp internal-sftp
   Match Group sftpgroup
   ChrootDirectory /home
   ForceCommand internal-sftp
   X11Forwarding no
   AllowTcpForwarding no

Save and exit the file, restart sshd service to take new changes into effect.

# systemctl restart sshd
# service sshd restart

If you chroot multiple users to the same directory, you should change the permissions of each user’s home directory in order to prevent all users to browse the home directories of the each other users.

# chmod 700 /home/tecmint

Verify SSH and SFTP Users Login

Now, it’s time to check the login from a local system. Try to ssh your remote system from your local system.

# ssh [email protected]


  1. tecmint – remote system’s username.
  2. – Remote system’s IP address.
Sample output:
[email protected]'s password: 
Could not chdir to home directory /home/tecmint: No such file or directory
This service allows sftp connections only.
Connection to closed.

Then, access remote system using SFTP.

# sftp [email protected]
Sample output:
[email protected]'s password: 
Connected to

Let us check the current working directory:

sftp&gt pwd
Remote working directory: /

sftp&gt ls

Here, tecmint is the home directory. Cd to the tecmint directory and create the files or folders of your choice.

sftp&gt cd tecmint
Remote working directory: /

sftp&gt mkdir test

Restrict Users to a Specific Directory

In our previous example, we restrict the existing users to the home directory. Now, we will see how to restrict a new user to a custom directory.

Create Group and New Users

Create a new group sftpgroup.

# groupadd sftpgroup

Next, create a directory for SFTP group and assign permissions for the root user.

# mkdir -p /sftpusers/chroot
# chown root:root /sftpusers/chroot/

Next, create new directories for each user, to which they will have full access. For example, we will create tecmint user and it’s new home directory with correct group permission using following series of commands.

# adduser tecmint -g sftpgroup -s /sbin/nologin
# passwd tecmint
# mkdir /sftpusers/chroot/tecmint
# chown tecmint:sftpgroup /sftpusers/chroot/tecmint/
# chmod 700 /sftpusers/chroot/tecmint/

Configure SSH for SFTP Access

Modify or add the following lines at the end of the file:

#Subsystem  	sftp	/usr/libexec/openssh/sftp-server
Subsystem sftp  internal-sftp
Match Group sftpgroup
   ChrootDirectory /sftpusers/chroot/
   ForceCommand internal-sftp
   X11Forwarding no
   AllowTcpForwarding no

Save and exit the file. Restart sshd service to take effect the saved changes.

# systemctl restart sshd
# service sshd restart

That’s it, you can check by logging into the your remote SSH and SFTP server by using the step provided above at Verify SSH and SFTP login.

Be mindful that this method will disable the shell access, i.e you can’t access the remote system’s shell session using SSH. You can only access the remote systems via SFTP and do file transfer to and from the local and remote systems.


Now you know how to restrict users home directories using a Chroot environment in Linux. If you find this useful, share this article on your social networks and let us know in the comment section below if there is any other methods to restrict users home directories.

Senthil Kumar
A Linux Consultant, living in India. He loves very much to write about Linux, Open Source, Computers and Internet. Apart from that, He'd like to review Internet tools and web services.

Each tutorial at TecMint is created by a team of experienced Linux system administrators so that it meets our high-quality standards.

Join the TecMint Weekly Newsletter (More Than 156,129 Linux Enthusiasts Have Subscribed)
Was this article helpful? Please add a comment or buy me a coffee to show your appreciation.


Leave a Reply
  1. Another case I couldn’t find anywhere…

    How to set a separate directory entry when they log in with the above configuration all users are pointing to the same directory (whatever is mentioned in the chrootdirectory).

    We have different clients logging into sftp and they need to be on different directory access.

  2. Hmm,

    All is well and good but when it comes to set:

    ForceCommand internal-sftp‘ or ‘Match Group SFTP‘ (any of these!) and I restart ssh, I’m getting “Failed to start OpenBSD Secure Shell server“.

  3. “adduser tecmint -g sftpgroup -s /sbin/nologin”

    It is not working for me.

    Even with this command:

    usermod -G webdev danielm
    --shell /sbin/false danielm

    Error: FATAL ERROR: Connection reset by peer
    Error: Could not connect to a server

    Thats outdated i think.

  4. Good Article.

    Have a question though, by doing the above steps, I see we could see the chroot jailed folder, after logging in. For a user, if he tries to log in, is it possible to show the complete path of the jailed folder, in this case, it would be, /sftpusers/chroot/tecmint/?

    Also by doing chroot jail, we are restricting every user to access only the assigned folder. Is it possible to have an admin kind of user, who could access these folders, and download the files and remove them?

  5. Good article, however on Ubuntu it simply doesn’t work. Or rather you won’t be able to use LFTP or Linux programs with it.

    If you want a good secure SFTP server you can’t beat Win server and the many paid SFTP programs that are out there. They at least work and won’t need weeks to figure out. As I have discovered as a system admin ‘free software’ usually means loads of hassle or it’s junk.

    • I came across this article while looking for something else and I found your comment interesting.

      I administer 4 cluster-based hypervisors deployed on 4 locations running a huge load of VMs all based either on Linux (all possible flavors) or Unix, some of them are running an SFTP on different Ubuntu versions set up in few minutes.

      This article describes pretty much all the basics to set up a secure FTP otherwise:

      $ man sshd_config

      Paid Win server SFTP you say?! There are good chances those are built on top of OpenSSH which is much better integrated to POSIX in regard to permissions.



  6. You can also try SFTPGo – it has chrooted support builtin, virtual quota, atomic uploads, bandwidth throttling and many other features.

    It can execute configurable custom commands and/or send HTTP notifications on upload, download, delete or rename.

    It is written in Go, so no runtime dependencies, and it works on Windows too

  7. I created SFTP Chroot for user XXX

    Subsystem sftp internal-sftp -l INFO -f AUTH
    Match Group sftp_g
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory /data/% u
    ForceCommand internal-sftp -l INFO -f AUTH

    I created user XXX and added to group sftp_g. I also created resource /data with permissions (root.root & 755).

    I added the XXX directory (root.root & 755). Here I added XXX (XXX.sftp_g)

    It works!

    I would like now that a completely different user has rights rwx for resource /data/xxx/xxx – if I add setfacl for user and resource /data – XXX stops working and can not connect – SSH logs bad permission.

    What should I do to have rwx for the user yyy for resource /data/xxx/xxx.


  8. This configuration show all directory from /home directory, but i want to restrict user in his own folder. Any suggestion.

    • Hi Bro,

      Change the /home to whichever directory you need the user should restricted to.

      Eg: ChrootDirectory /home/

  9. Hello,

    Great article and it helped me resolve my problem. However, I have one more little problem that I cannot seem to figure out and it is to do with WinSCP and chroot.

    My issue is that when I use WinSCP to connect to the server I have set up it will work correctly except that the user and owner do not show up correctly. It shows as the UID and GID rather than the actual owner and group.

    It will show the User as a value of 0 and Group as 1005. Its pulling the values from the /etc/group file.

    When I access it via the shell it shows correct permissions for user/group

    -rwxrwsr-x+  1 root nycdata    132 Mar  5 13:58 testfile.txt

    So what I did to try correct this is that I copied the /etc/group and /etc/passwd files to the chrooted folder. Within the chrooted folder I created a folder called /etc. Also I created a folder called /bin and I dropped this into /etc of the chrooted folder.

    However I still cannot see the correct permissions when I use WinSCP. Though I have not tried FileZilla. The issue is that I will be having users connecting via WinScp or Filezilla and I would like them to be able to see their files easily.

    Not sure where I am going wrong but any advise would be great.

    Thank you so much,

  10. Thanks for the article. I’m learning about SFTP now and was curious and wanted to know how to CHROOT its users from Centos 7.

  11. On my freeBSD server, everything works fine until I try to rsync.

    If I do: sftp [email protected], I get “Connected to ip.address” like in your article above.

    But if I do: rsync -avz [email protected]/ /path/to/local/backup, then I get the following:

    protocol version mismatch — is your shell clean?
    (see the rsync man page for an explanation)
    rsync error: protocol incompatibility (code 2) at /SourceCache/rsync/rsync-42/rsync/compat.c(61) [receiver=2.6.9]

    Any ideas? Thanks

    • @Robert,

      I think its due to different versions of rsync installed on servers, make sure you have same version of rsync or may be different flavors of Linux distros used here, you need to check..

  12. You’re better of creating a SFTP root as /home/sftproot and then putting your SFTP users home directories under /home/sftproot/home.
    Then when that user logs in they’ll automatically get put into their home directory e.g. /home/lenny within the chroot instead of the root directory of the chroot. You can then also restrict permissions so that within the chroot /home directory users can’t see what other user directories exist, chmod 0751
    You can also configure rsyslog to add a socket to /home/sftproot/dev/ so ssh logs all transfers to syslog.


Got Something to Say? Join the Discussion...

Thank you for taking the time to share your thoughts with us. We appreciate your decision to leave a comment and value your contribution to the discussion. It's important to note that we moderate all comments in accordance with our comment policy to ensure a respectful and constructive conversation.

Rest assured that your email address will remain private and will not be published or shared with anyone. We prioritize the privacy and security of our users.