Home

How to create an SFTP chroot jail easily on Debian with scponly

2007, November 23 - 21:33 — müzso
What's 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 connection

If 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 connection

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 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
And of course use your chrooted dir instead of /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.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
2009, January 25 - 23:56 — müzso

Debugging scponly issues

There's a great howto at Ubuntu Forums on how to configure scponly with chroot jail. Among the responses there're very good tips on debugging scponly issues. My current issue was with ACLs. The chrooted home of the user had ACLs associated with it and scponly did 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 lib directory 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) under lib resulted in "Permission denied" error again.

And yet another issue was that when using scp to copy something to the server, I got the following error message:
Could not chdir to home directory /home/scponly//incoming: Permission denied

I'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"
And got:
bash: line 0: cd: /home/scponly/incoming: Permission denied

Now I just had to resolve why I got that error. It turned out that /home/scponly was 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/scponly to "scponly". After that the "Permission denied" error was gone and both scp and sftp worked without a hitch.

Syndicate content