Secure SFTP Server Setup on Linux: How to Restrict Users to a Single Folder

All usernames, paths and IP addresses below are placeholders. The IP 203.0.113.25 is from a range reserved for documentation (RFC 5737).

Quick answer

A secure SFTP server setup on Linux restricts each user to a single folder using OpenSSH's built-in internal-sftp together with ChrootDirectory. You create a dedicated group and a user with no shell, build a directory tree owned by root, give the user write access to only one subfolder, and add a Match User block to /etc/ssh/sshd_config. After validating with sshd -t, you reload SSH. The user can then upload files over SFTP, but cannot open a shell, forward ports, or see anything outside their folder.

Why a secure SFTP server setup matters

A secure SFTP server setup becomes essential the moment someone outside your team needs to send you files. It might be a partner dropping daily reports, a customer uploading documents, or a vendor sharing batch exports. Email is not an option, and a public file-sharing link is not something you want to defend in an audit.

SFTP is the natural choice. It runs over SSH, so the traffic is encrypted end to end. The catch is that a regular SSH account gives far more than file transfer. Out of the box, that user can open a shell, browse your file system, and tunnel traffic through your server.

I recently set this up on my own server for exactly that reason: one external party, one upload folder, nothing else. This guide walks through the exact commands I used, explains why each one matters, and covers the mistakes that usually trip people up.

If you work with frameworks such as PCI DSS, SOC 2 or ISO 27001, this setup also maps neatly to least-privilege and access-control requirements.

Prerequisites

Before you begin your secure SFTP server setup, make sure you have the following in place:

• A Linux server running OpenSSH (this guide was tested on Ubuntu; Debian works the same way, and RHEL-based systems differ only in the service name).

• A user account with sudo privileges.

• A second, already-open SSH session as your admin user. If you make a mistake in sshd_config, this session is your way back in.

• The public IP address your SFTP client will connect from, if you want to restrict access by source IP.

Check your OpenSSH version with ssh -V. Any release from the last several years supports every directive used here.

All usernames, paths and IP addresses in this guide are placeholders. The IP 203.0.113.25 is from a range reserved for documentation (RFC 5737).

How does SFTP chroot work?

A chroot jail changes what a process sees as the root directory /. When our SFTP user logs in, OpenSSH switches their root to a folder we choose. From their point of view, that folder is the entire server.

Here is the rule behind most failed logins in a secure SFTP server setup: the chroot directory and every directory above it must be owned by root and must not be writable by any other user or group. OpenSSH enforces this strictly. If any directory in the path is writable by someone else, a user could potentially plant files that escape the jail, so SSH refuses the connection.

The sshd_config(5) manual states this requirement directly: every component of the ChrootDirectory path must be a root-owned directory that no other user or group can write to. Built-in SFTP chroot support has been part of OpenSSH since version 4.9 (Arch Wiki).

That creates a small puzzle. If the user cannot write to their chroot root, where do they upload? The answer is a subfolder inside the jail that they do own. That is why our layout looks like this:

Secure SFTP server setup: step-by-step guide

Step 1: Create a dedicated SFTP group

A group gives you one place to manage every SFTP-only user later on. The -f flag means the command will not fail if the group already exists, which keeps it safe to re-run.

sudo groupadd -f sftpusers

Step 2: Create the user without a home directory or shell

This user should never log in interactively, so we give them no home directory and a shell that rejects logins.

sudo useradd -M -d / -s /usr/sbin/nologin -g sftpusers partner01

Here is what each option does:

• -M skips creating a home directory under /home.

• -d / sets the home directory to /. After the chroot, / is the jail itself, so the user lands right inside it.

• -s /usr/sbin/nologin blocks shell access even if the SFTP restriction were ever removed.

• -g sftpusers sets the primary group.

Step 3: Set a strong password

sudo passwd partner01

Use a long, randomly generated password and share it through a secure channel. Better still, switch to SSH key authentication once the setup works (covered in the hardening section).

Step 4: Create the directory structure

sudo mkdir -p /srv/external/vendor/abcd/upload

The -p flag creates every missing parent along the way.

Step 5: Lock down ownership for the chroot path

This is the step that makes or breaks the setup. Every directory from /srv/external down to the jail must be owned by root with mode 755. On a standard install, /srv and / already meet this requirement.

# The chroot directory itself must be owned by root
sudo chown root:root /srv/external/vendor/abcd
sudo chmod 755 /srv/external/vendor/abcd

# Every parent directory must meet the same requirement
sudo chown root:root /srv/external/vendor
sudo chmod 755 /srv/external/vendor
sudo chown root:root /srv/external
sudo chmod 755 /srv/external

Mode 755 means root can write, and everyone else can only read and traverse. That satisfies OpenSSH's ownership check.

Step 6: Give the user write access to the upload folder

sudo chown partner01:sftpusers /srv/external/vendor/abcd/upload
sudo chmod 750 /srv/external/vendor/abcd/upload

With 750, the user has full control, the group can read, and nobody else can see inside. This is the only place the user can create files.

Step 7: Create a custom SFTP banner

A login banner tells users the system is private and monitored. It is a small touch, but auditors like it, and it supports legal action if someone misuses the access.

sudo nano /etc/ssh/sftp-banner

Add a short notice, for example:

*******************************************************************
  Authorised access only. This system is monitored and all
  activity is logged. Disconnect now if you are not authorised.
*******************************************************************

Then set safe permissions on the file:

sudo chown root:root /etc/ssh/sftp-banner
sudo chmod 644 /etc/ssh/sftp-banner

Step 8: Configure sshd_config

Always take a backup before editing:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
sudo nano /etc/ssh/sshd_config

First, make sure the SFTP subsystem uses the built-in server. Find the existing Subsystem sftp line and change it to:

Subsystem sftp internal-sftp

Next, add the following at the very end of the file:

# Only these accounts may log in via SSH/SFTP
AllowUsers partner01@203.0.113.25 adminuser

# SFTP-only jail for partner01
Match User partner01
    ChrootDirectory /srv/external/vendor/abcd
    ForceCommand internal-sftp -l INFO
    DisableForwarding yes
    PermitTTY no
    AllowTcpForwarding no
    AllowAgentForwarding no
    X11Forwarding no
    Banner /etc/ssh/sftp-banner

Two details matter here. First, AllowUsers must sit above the Match block. Everything after a Match line applies only to that match, until the next Match or the end of the file. Second, the AllowUsers list is a whitelist: any account not listed is denied, including your own admin user. Add every admin account you rely on before you reload, or you will lock yourself out.

Step 9: Validate and reload SSH

sudo sshd -t && sudo systemctl reload ssh

sshd -t checks the configuration for syntax errors. The && ensures the reload only happens if the test passes. On RHEL, Rocky Linux or AlmaLinux, the service is called sshd instead of ssh.

What does each sshd_config directive do?

Each directive in the Match User block removes one capability from the account, so that only file transfer inside the jail remains.

The overlap is deliberate. OpenSSH added DisableForwarding in version 7.4, released on 19 December 2016 (release notes). However, from 7.4 up to but not including 10.0, the directive did not disable X11 and agent forwarding as documented. This is tracked as CVE-2025-32728, with an NVD CVSS 3.1 base score of 3.8 (AWS ALAS). Setting X11Forwarding no, AllowTcpForwarding no and AllowAgentForwarding no explicitly closes that gap on servers that are not yet patched.

How do you test a secure SFTP server setup?

You test a secure SFTP server setup by trying to break it: log in, try to leave the jail, write outside the upload folder, open a shell and connect from an unlisted IP. Run these checks from the allowed client IP.

1. Confirm SFTP login works

sftp partner01@your-server-ip

You should see your banner, then the sftp> prompt.

2. Confirm the user is jailed

sftp> pwd
Remote working directory: /
sftp> ls
upload
sftp> cd /etc
Couldn't stat remote file: No such file or directory

3. Confirm uploads work only in the upload folder

sftp> put test.txt
remote open("/test.txt"): Permission denied
sftp> cd upload
sftp> put test.txt

The first upload should fail and the second should succeed.

4. Confirm shell access is blocked

ssh partner01@your-server-ip

The connection should close straight away with a message such as "This service allows sftp connections only."

5. Confirm the IP restriction

Try connecting from any other IP address. The login should be rejected.

6. Inspect the effective configuration

This prints the settings sshd will apply for a given connection, which is handy for audits:

sudo sshd -T -C user=partner01,host=client,addr=203.0.113.25 | grep -Ei 'chroot|forcecommand|forwarding|permittty'

Hardening tips for production

The steps above give your secure SFTP server setup a solid baseline. For a server that handles sensitive data, I strongly recommend going a few steps further.

Never allow direct root login. It is tempting to add root to AllowUsers for convenience, but it widens your attack surface considerably. Log in as a named admin and use sudo instead, and set PermitRootLogin no in the global section.

Keep OpenSSH patched. SSH is internet-facing, so the version you run matters. CVE-2024-6387 (regreSSHion), reported by Qualys on 1 July 2024, allows unauthenticated remote code execution on glibc-based Linux. It affects OpenSSH 8.5p1 to 9.7p1, carries a CVSS score of 8.1 and is fixed in 9.8p1 (Unit 42). Distributions often backport fixes, so check your vendor's advisory rather than relying on the version number alone.

Switch to SSH key authentication. Passwords can be guessed, phished or reused. Create the folder /etc/ssh/authorized_keys/, store the partner's public key at /etc/ssh/authorized_keys/partner01 (owned by root, mode 644), and add these lines inside the Match block:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u
    PasswordAuthentication no

The keys live outside the jail, so the user cannot modify them.

Add rate limiting. OpenSSH defaults to MaxAuthTries 6 and LoginGraceTime 2m (default sshd_config). Lowering these to MaxAuthTries 3 and LoginGraceTime 30, and adding Fail2ban, slows down brute-force attempts considerably.

Firewall the SSH port. Allowing port 22 only from known IPs at the firewall level gives you a second barrier if sshd_config is ever misconfigured.

Forward the logs. The -l INFO flag writes every upload, download and deletion to the auth log. Ship those logs to your SIEM so you have a tamper-resistant audit trail. This supports SOC 2 monitoring controls and PCI DSS Requirement 10.5.1, which requires at least 12 months of audit log history with the latest three months immediately available (Microsoft Learn).

Scan and clean uploaded files. Treat everything a third party uploads as untrusted. Run malware scanning on the upload folder and set a retention policy so files do not pile up.

Mount the data with restrictive options. If /srv/external sits on its own partition, mount it with noexec,nosuid,nodev so uploaded files cannot be executed.

Review access regularly. When a partnership ends, lock the account straight away with sudo usermod -L partner01 and remove it from AllowUsers.

Troubleshooting common SFTP chroot errors

When a secure SFTP server setup goes wrong, the server log almost always tells you why. Watch it live while you retry the login:

sudo journalctl -u ssh -f
# or, on older systems
sudo tail -f /var/log/auth.log

A quick way to check the whole chroot path in one go:

namei -l /srv/external/vendor/abcd/upload

# namei -l /srv/external/vendor/abcd/upload - result of this command below
f: /srv/external/vendor/abcd/upload
drwxr-xr-x root                 root      /
drwxr-xr-x root                 root      srv
drwxr-xr-x root                 root      external
drwxr-xr-x root                 root      vendor
drwxr-xr-x root                 root      abcd
drwxr-x--- partner01            sftpusers upload