In order to enable chrooted SFTP for some users, we ll first create a separate gro up for users that will

get the chroot treatment. I named this group chrooted, fo r no obvious reason. This group will be assigned as a supplementary group for ch root users. The common application for this will be virtual WWW hosting, so I started with t he assumption that a website called www.example.com will be accessed by SFTP. Th e directory /vhost/www.example.com will therefore serve as the user s home directo ry. In order to make chrooting work along with key-based authentication, I found that it neccessary to make the user name and the name of his home directory ide ntical, so the user was named www.example.com as well (login shell: /bin/false), along with a similar user private group www.example.com. This looks as if it ma y have a tendency to get awkward, but it really only is a first test. I ll have to invest a bit more thought before this goes into production. The directory /vhost/www.example.com was created and populated like this: drwxr-xr-x drwxr-xr-x drwxrwxr-x drwxr-xr-x drwxr-xr-x 5 3 2 2 2 root root www.example.com root www.example.com root root www.example.com root www.example.com 4096 4096 4096 4096 4096 Apr Apr Apr Apr Apr 5 5 6 5 5 22:01 21:22 08:45 21:22 22:02 . .. htdocs logs .ssh

With the user created and his directory populated, we ll now edit sshd_config as f ollows: #Replace the OpenSSH sftp-server backend with its internal SFTP engine: #Subsystem sftp /opt/openssh/libexec/sftp-server Subsystem sftp internal-sftp # Configure special treatment of members of the group chrooted: Match group chrooted # chroot members into this directory # %u gets substituted with the user name: ChrootDirectory /vhost/%u X11Forwarding no AllowTcpForwarding no # Force the internal SFTP engine upon them: ForceCommand internal-sftp I actually had a quite hard time figuring out the proper constellation of user n ame, user home directory and ChrootDirectory. ChrootDirectory applies after the user has been authenticated. Before that, his home directory from /etc/passwd st ill applies. In order to enable the user to maintain his SSH key and to enable s shd to find the key, both environments must be congruent. However, the chroot de stination must not be owned by the user for security reasons; the user s home dire ctory therefore belongs to root. Tricky, isn t it? I must admit, though, that this would have been a lot more intuitive if I hadn t strayed away from /home on the v ery first test. Doh! :-o Here s a sample session with the user www.example.com , authenticated by public key: $ sftp www.example.com@192.168.1.24 Connecting to 192.168.1.24... sftp> ls -la drwxr-xr-x 5 0 0 drwxr-xr-x 5 0 0 drwxr-xr-x 2 59984 59984 drwxrwxr-x 2 59984 59984 drwxr-xr-x 2 0 0 sftp> pwd

4096 4096 4096 4096 4096

Apr Apr Apr Apr Apr

5 5 5 6 5

20:01 20:01 20:02 07:32 19:22

. .. .ssh htdocs logs

Remote working directory: / sftp> cd .. sftp> ls -la drwxr-xr-x 5 0 0 drwxr-xr-x 5 0 0 drwxr-xr-x 2 59984 59984 drwxrwxr-x 2 59984 59984 drwxr-xr-x 2 0 0 sftp> pwd Remote working directory: / sftp> ls -la .ssh drwxr-xr-x 2 59984 59984 drwxr-xr-x 5 0 0 -r-------1 59984 59984 sftp> bye

4096 4096 4096 4096 4096

Apr Apr Apr Apr Apr

5 5 5 6 5

20:01 20:01 20:02 07:32 19:22

. .. .ssh htdocs logs

4096 Apr 5 20:02 . 4096 Apr 5 20:01 .. 601 Apr 5 20:02 authorized_keys

Pay attention to the UIDs, 0 and 59984: The SFTP subsystem, running under chroot , doesn't have access to /etc/passwd from the user's environment. I am convinced that this is the most important update to OpenSSH for at least th e past five years. This has the opportunity to entirely eradicate authenticated FTP from the internet, just as it has already happened with Telnet. Thanks a lot to the OpenSSH developers for making this happen!