Configuring an SFTP directory on a Linux server to accept files from multiple sources requires isolating each source into its own chrooted environment. This approach ensures that external partners or internal applications can upload data without accessing other users' directories or system files. By leveraging OpenSSH's built-in subsystem capabilities and group permissions, you can create a secure, scalable architecture for file ingestion.
Creating the Directory Structure
The foundation of a multi-source SFTP setup is a logical directory hierarchy that separates incoming data streams. You should create a base directory, typically at
/srv/sftp, which will house individual subdirectories for each distinct file source. For example, if you have two vendors, VendorA and VendorB, you would create paths like
/srv/sftp/vendor_a and
/srv/sftp/vendor_b.
It is critical that these directories are owned by the root user but writable by specific service accounts. This ownership structure allows the SSH daemon to chroot (change the root directory) to the user's home directory while still permitting uploads. To set this up, use the following commands:
sudo mkdir -p /srv/sftp/vendor_a
sudo mkdir -p /srv/sftp/vendor_b
sudo chown root:root /srv/sftp/vendor_a
sudo chown root:root /srv/sftp/vendor_b
Next, create dedicated groups for each source to manage access control effectively. Assign the respective users to these groups. This step is vital because it allows you to grant write permissions to specific folders without granting them to others, ensuring strict isolation between different file sources.
Configuring User Accounts and Permissions
Each external source should have its own Linux user account. These accounts must be configured with no login shell to prevent direct SSH access, restricting their activity strictly to SFTP. Create the users using the
-s /usr/sbin/nologin flag to disable interactive shells. Then, assign them to their respective groups.
For instance, to create a user for VendorA:
sudo useradd -m -d /srv/sftp/vendor_a -s /usr/sbin/nologin vendor_a_user
sudo usermod -aG sftp_group vendor_a_user
Ensure that the home directory has the correct permissions. The parent directory must be owned by root, while the actual upload folder inside the chroot needs to be writable by the user. A common mistake is setting the home directory itself as writable; instead, create a subdirectory within the chroot for uploads. For example, inside
/srv/sftp/vendor_a, create an
uploads folder owned by the user. This maintains the security requirement that the chroot directory is not writable by the user, while still allowing them to save files in the designated area.
Modifying the SSH Daemon Configuration
The core of the isolation mechanism lies in the
/etc/ssh/sshd_config file. You need to define a Match block that applies specific settings only to users belonging to the SFTP group. This configuration utilizes the
ChrootDirectory directive to restrict the user's view of the filesystem to their assigned directory.
Add the following lines to the end of your
sshd_config:
Match Group sftp_group
ChrootDirectory /srv/sftp/%u
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
The
%u variable automatically substitutes the username, mapping
vendor_a_user to
/srv/sftp/vendor_a. This dynamic mapping allows you to add new sources simply by creating a new directory and user, without modifying the SSH configuration again. After editing the file, restart the SSH service to apply changes:
sudo systemctl restart sshd
This setup ensures that when
vendor_a_user logs in via SFTP, they are immediately placed in
/srv/sftp/vendor_a and cannot navigate up to the parent directory or access other vendors' data.
Testing and Troubleshooting
Once the configuration is in place, test the connection using an SFTP client. Attempt to list files and upload a test document. If the user cannot write to the directory, verify that the inner
uploads folder has the correct ownership. Remember that the chroot directory itself must remain owned by root; only the subdirectories inside it can be owned by the user.
If you encounter permission denied errors, check the SELinux context on the directories, especially on RHEL-based systems. You may need to restore the default context using
restorecon -Rv /srv/sftp. Additionally, review the system logs at
/var/log/auth.log or
/var/log/secure for detailed error messages regarding authentication or subsystem failures. For more complex scenarios involving password issues during transfer, see
How to Overcome Problems with a Password Requiring at Transferring a File from Linux Centos 7 to Linux Synology.
Frequently Asked Questions
Can I allow SFTP users to access other directories?
No, the primary purpose of ChrootDirectory is to restrict users to their specific environment. Allowing access to other directories would compromise security and isolation between different file sources.
What happens if I change the ownership of the chroot directory?
OpenSSH requires the chroot directory and all its parents to be owned by root. If you change the ownership to the user, the SFTP session will fail with a permission denied error upon login.
How do I add a third vendor to this setup?
You simply create a new directory under
/srv/sftp, create a new user with nologin shell, assign them to the same SFTP group, and ensure the internal upload folder is writable by that user. No SSH config changes are needed.
Why can't my user upload files even though permissions seem correct?
Check if the user is trying to write directly to the chroot root directory. They must write to a subdirectory (like
uploads) that is owned by them, as the chroot root itself must be owned by root.
Is it possible to use key-based authentication with this setup?
Yes, key-based authentication works seamlessly with chrooted SFTP. Configure the public keys in the user's
.ssh/authorized_keys file just as you would for any other SSH user.