SFTP chroot

From ArchWiki
Revision as of 11:26, 21 February 2013 by Seiichiro0185 (talk | contribs) (Changes for new pam handling in sshd)
Jump to: navigation, search

OpenSSH 4.9+ includes a built-in chroot for sftp, but requires a few tweaks to the normal install.


This package is available in the core repository. To install it, run

# pacman -S openssh


In /etc/ssh/sshd_config, modify the Subsystem line for sftp:

 Subsystem       sftp    internal-sftp

At the end of the file, add something similar to the following for a group:

 Match Group sftpusers
   ChrootDirectory %h
   ForceCommand internal-sftp
   AllowTcpForwarding no

Or for a user:

 Match User username
   ChrootDirectory %h
   ForceCommand internal-sftp

The %h represents the users home directory.

Change ownership of chrooted dir to root (for more details see at the end):

chown root ~user

Restart sshd:

# /etc/rc.d/sshd restart

Adding new chrooted users

If using the group method above, ensure all sftp users are put in the appropriate group, i.e.:

 usermod -g sftpusers

Also, set their shell to /bin/false to prevent a normal ssh login:

 usermod -s /sbin/nologin

You also need to add /sbin/nologin to /etc/shells, or the sftp-users won't be able to login.

Note that since this is only for sftp, a proper chroot environment with a shell and /dev/* doesn't need to be created.

Their chroot will be the same as their home directory. The permissions are not the same as a normal home, though. Their home directory must be owned as root and not writable by another user or group. This includes the path leading to the directory. My recommendation is to use /usr/local/chroot as a root and build the home directories under that.



The user will not be able to access /dev/log. This can be seen by running strace on the process once the user connects and attempts to download a file. Create the sub-dircetory dev in the ChrootDirectory, for example:

 sudo mkdir /usr/local/chroot/theuser/dev
 sudo chmod 755 /usr/local/chroot/theuser/dev

syslog-ng will create the device /usr/local/chroot/theuser/dev/log once configured.


Add to /etc/syslog-ng/syslog-ng.conf a new source for the log and add the configuration, for example change the section:

source src {


source src {

and append:

#sftp configuration
destination sftp { file("/var/log/sftp.log"); };
filter f_sftp { program("internal-sftp"); };
log { source(src); filter(f_sftp); destination(sftp); };

(Optional) If you'd like to similarly log SSH messages to it's own file:

#sshd configuration
destination ssh { file("/var/log/ssh.log"); };
filter f_ssh { program("sshd"); };
log { source(src); filter(f_ssh); destination(ssh); };

(From Syslog-ng#Move_log_to_another_file)


Edit /etc/ssh/sshd_config to replace all instances of internal-sftp with internal-sftp -f AUTH -l VERBOSE


Restart logging and SSH:

 /etc/rc.d/syslog-ng restart
 /etc/rc.d/ssh restart

/usr/local/chroot/theuser/dev/log should now exist.

Testing your chroot

# ssh username@localhost

should refuse the connection or fail on login. The response varies, possibly due to the version of OpenSSH used.

# sftp username@localhost

should place you in the chroot'd environment.


Error while trying to connect

Write failed: Broken pipe                                                                                               
Couldn't read packet: Connection reset by peer

If you also find similar message in /var/log/auth.log

sshd[12399]: fatal: bad ownership or modes for chroot directory component "/path/of/chroot/directory/"  

It's ChrootDirectory ownership problem, sshd will reject sftp connections to accounts that are set to chroot into any directory that has ownership/permissions that sshd doesn't consider secure. sshd's apparently strict ownership/permissions requirements dictate that every directory in the chroot path must be owned by root and only writable for the owner. So, for example, if the chroot environment is in a user's home directory both /home and /home/username must be owned by root and have permissions along the lines of 755 or 750 ( group ownership should allow user to access ).

If chroot environment is in user's home directory, make sure user have access to it's home directory, or user would not be able to access it's publickey, produce following error

Permission denied (publickey).

Links & References