How to create an SFTP chroot jail easily on Debian with scponly
Fri, 2007.11.23 - 21:33 — müzso
What's
A typical usage of scponly is in creating a semi-public account not unlike the concept of anonymous login for ftp. This allows an administrator to share files in the same way an anon ftp setup would, only employing all the protection that ssh provides. This is especially significant if you consider that ftp authentications traverse public networks in a plaintext format."
Fortunately there's a Debian package for
However if you just follow those steps, you'll not be able to use
If you turn on debugging by changing the value on the sftp server in
Actually this is not telling any more than the original error message with debugging disabled, but at least you know now that there's nothing else wrong except for the unknown user thing.
The problem is with the
And of course use your chrooted dir instead of
PS: be aware that symlinks pointing out of the chroot will not work. So eg. if you chroot a tomcat55 user into the
scponly? Here's a quote from its official website: "scponly is an alternative 'shell' (of sorts) for system administrators who would like to provide access to remote users to both read and write local files without providing any remote execution priviledges. Functionally, it is best described as a wrapper to the tried and true ssh suite of applications.A typical usage of scponly is in creating a semi-public account not unlike the concept of anonymous login for ftp. This allows an administrator to share files in the same way an anon ftp setup would, only employing all the protection that ssh provides. This is especially significant if you consider that ftp authentications traverse public networks in a plaintext format."
Fortunately there's a Debian package for
scponly and the main steps are described pretty well in the scponly FAQ (look at the bottom of the page in the "Chroot and Debian" section).However if you just follow those steps, you'll not be able to use
scp or sftp. You'll get the following error message if you try to scp a file to the server:unknown user 1002
lost connectionIf you turn on debugging by changing the value on the sftp server in
/etc/scponly/debuglevel from the default 0 to 2 and try to scp a file with the chrooted user to the sftp server, you'll get tons of debug messages at the scp client:scponly[6820]: chrooted binary in place, will chroot()
scponly[6820]: 3 arguments in total.
scponly[6820]: arg 0 is scponlyc
scponly[6820]: arg 1 is -c
scponly[6820]: arg 2 is scp -t /incoming
scponly[6820]: opened log at LOG_AUTHPRIV, opts 0x00000029
scponly[6820]: retrieved home directory of "/home/test" for user "test"
scponly[6820]: chrooting to dir: "/home/test"
scponly[6820]: chdiring to dir: "/"
scponly[6820]: chdiring to dir: "/"
scponly[6820]: setting uid to 1002
scponly[6820]: processing request: "scp -t /incoming"
scponly[6820]: Found "HOME" and setting it to "/home/test"
scponly[6820]: Environment contains "HOME=/home/test"
scponly[6820]: set HOME environment variable to / username: test(1002), IP/port: 192.168.0.3 50355 22
scponly[6820]: running: /usr/bin/scp -t /incoming (username: test(1002), IP/port: 192.168.0.3 50355 22)
unknown user 1002
lost connectionActually this is not telling any more than the original error message with debugging disabled, but at least you know now that there's nothing else wrong except for the unknown user thing.
The problem is with the
passwd file inside the chroot. The sftp-server cannot read it. Normally /etc/passwd is world-readable, but the setup_chroot.sh script (that comes with scponly) does not explicitly set the permissions on the chrooted passwd, so it's created with the umask that your shell had at the moment of execution of the script. To fix this you just have to execute:chmod a+r /home/test/etc/passwd/home/test.PS: be aware that symlinks pointing out of the chroot will not work. So eg. if you chroot a tomcat55 user into the
/var/lib/tomcat5.5 directory where the log symlink points to ../../log/tomcat5.5, then the user will not be able to enter the log directory/symlink.
All of my own contents here (if not noted otherwise) are licensed under the
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License. My posts reflect my personal opinion and shall not be associated with any of my employers.
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License. My posts reflect my personal opinion and shall not be associated with any of my employers.
Comments
Debugging scponly issues
scponlydid not like it (complained about some "Permission denied" errors). So I removed all ACLs on the chroot dir and ended up with permissions like this:drwxr-xr-x 8 root root 4096 2009-01-25 22:53 ./That worked. Another issue is that the libs inside the chrooted
libdirectory have to have execute permission for all on them. I'm not sure whether all libs need this or only one (or just a few), but removing the execute permission from all files (and just the files) underlibresulted in "Permission denied" error again.And yet another issue was that when using
scpto copy something to the server, I got the following error message:Could not chdir to home directory /home/scponly//incoming: Permission deniedI've checked this by trying to change directory on the server with the scponly user. Executed as root:
su -s /bin/sh scponly -c "cd /home/scponly//incoming"bash: line 0: cd: /home/scponly/incoming: Permission deniedNow I just had to resolve why I got that error. It turned out that
/home/scponlywas assigned to "root" user and "root" group and the permissions were "rwxr-x---", thus only root had right to it (and the "scponly" user had right only to the "incoming" subfolder). I did not want to add world-readable permission to scponly's home directory, so to fix the problem I've changed the group of/home/scponlyto "scponly". After that the "Permission denied" error was gone and both scp and sftp worked without a hitch.