OpenSSH rejects the chroot directory because it has incorrect ownership or permissions. The directory must be owned by root and not writable by group or other users, for security reasons.
When SSHD is configured with ChrootDirectory to jail SFTP or SSH users, OpenSSH performs strict security checks on the chroot directory and its parent directories. If ownership or permission bits don't match OpenSSH's strict requirements, the connection fails immediately with this error. This is a deliberate security restriction to prevent privilege escalation attacks through chroot jails.
First, examine the current state of your chroot directory and its parent path:
ls -ld /path/to/chroot
ls -ld /path/to
ls -ld /path
ls -ld /Look for any directories that aren't owned by root or have write permissions for group/other users. The output should show:
drwxr-xr-x root rootIf you see permissions like drwxrwx--- or drwxrwxr-x or group ownership other than root/wheel, that's the problem.
Change the chroot directory to be owned by root:root (or root:wheel on BSD systems):
sudo chown root:root /path/to/chrootFor example, if your chroot is /home/sftpuser:
sudo chown root:root /home/sftpuserRemove all write permissions for group and other users. The chroot directory must have exactly 755 permissions:
sudo chmod 755 /path/to/chrootThis sets:
- Owner (root): read, write, execute (rwx)
- Group: read, execute only (r-x)
- Other: read, execute only (r-x)
Verify with:
ls -ld /path/to/chrootShould show: drwxr-xr-x
OpenSSH checks the entire path from root to the chroot directory. Each parent directory must also be owned by root and not writable by group/other:
sudo chown root:root /path/to
sudo chmod 755 /path/toRepeat for each directory in the path. For most systems, /, /home, /var, etc. should already be correct, but check if you're using custom paths.
Users need a place to write files inside the chroot. Create a subdirectory owned by the user:
sudo mkdir -p /path/to/chroot/upload
sudo chown sftpuser:sftpuser /path/to/chroot/upload
sudo chmod 755 /path/to/chroot/uploadThe user will only be able to write to subdirectories they own, not to the chroot root itself. This is the expected and secure behavior.
After fixing ownership and permissions, reload the SSH daemon (be careful not to lock yourself out):
sudo sshd -tIf the test passes, reload:
sudo systemctl reload ssh
# or on some systems:
sudo systemctl reload sshdThen test the SFTP connection from a client:
sftp sftpuser@yourserverYou should now get a password prompt and be able to connect.
Why is OpenSSH so strict about chroot ownership? If a non-root user owned the chroot directory, they could modify files within it (including binaries or configuration for internal-sftp), potentially leading to privilege escalation. By requiring root ownership and read-only permissions for non-root users, OpenSSH ensures the chroot jail cannot be tampered with from within.
On BSD systems, the group may be 'wheel' instead of 'root', but the principle is the same: the directory must be owned by root and not writable by others.
If using 'internal-sftp' (recommended), ensure your sshd_config has: ForceCommand internal-sftp in the Match block. This avoids needing shell binaries in the chroot.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH