Clone this wiki locally
In order to figure out what's going on, we need to know a what you expect scponly to do and what scponly is actually doing. The best way to help us figure out what scponly is actually doing is to turn on logging. Once you have log output, please post an e-mail to the scponly mailing list.
When scponly or scponlyc start up, they check the contents of a file called /usr/local/etc/scponly/debuglevel. During normal operation, the value in this file is '0'. To increase the verbosity of scponly output, increase this number (1 and 2 are the only other values which will do anything, however).
echo 2 > /usr/local/etc/scponly/debuglevel
Ubuntu has its debuglevel file in a different place, as such you need to use the following command:
sudo echo 2 > /etc/scponly/debuglevel
Setting /usr/local/etc/scponly/debuglevel to 2 results in additional debug information being sent to syslog, which will look something like this:
$ scp file firstname.lastname@example.org:incoming/ email@example.com's password: scponly: chrooted binary in place, will chroot() scponly: 3 arguments in total. scponly: arg 0 is scponlyc scponly: arg 1 is -c scponly: arg 2 is scp -t incoming/ scponly: opened log at LOG_AUTHPRIV, opts 0x00000029 scponly: retrieved home directory of "/home/ftpusers/scpuser" for user "scpuser" scponly: chrooting to dir: "/home/ftpusers/scpuser" scponly: chdiring to dir: "/" scponly: setting uid to 504 scponly: processing request: "scp -t incoming/" scponly: denied request: scp -t incoming/ [username: scpuser(504), IP/port: ::ffff:10.y.y.y 56642 22] lost connection
If nothing is obvious after looking at the logs, you might consider posting to the https://lists.ccs.neu.edu/bin/listinfo/scponly scponly mailing list after searching the https://lists.ccs.neu.edu/pipermail/scponly/ archives to see if anybody else has had the same problem.
If after the above steps there still isn't a solution, you could also try tracing the scponly process, to determine what it is doing at the system-level:
Depending on your platform, you will need to investigate strace, ktrace, or truss. Once you are familiarized with your particular brand of trace tool, you could follow the strategy below:
First, from the client:
$ sftp username at hostname
from the server (this will look different if you aren't using privilege separation):
$ ps -Af | grep -i username root 10206 16786 0 15:41 ? 00:00:00 sshd: username [priv] sshd 10207 10206 0 15:41 ? 00:00:00 sshd: username [net] root 10215 18650 0 15:42 pts/2 00:00:00 grep -i username
Still on server, now knowing PIDs, the main PID of interest is the privileged one running as root. In this case it's PID 10206:
$ strace -o sftp.log -f -ff -p 10206
NOTE: make sure you substitute the right PID above. if the above fails you might need to pull up the man page for your strace variant and make sure that the options specified are valid.
from the client: [finish][execute] [quit]
Now, you can take a look at sftp.log and find out what's going on. There will be several sftp.log. files created. You'll be interested in the one that exec's the scponly process. To find it, you should be able to do something like the following:
$ grep "^exec" sftp.log* sftp.log.8239:execve("/usr/bin/scponly", ["scponly", "-c", "/usr/lib/openssh/sftp-server"], [/* 10 vars */]) = 0 sftp.log.8239:execve("/usr/lib/sftp-server", ["/usr/lib/sftp-server"], [/* 2 vars */]) = 0
So, to see what happens after the execution of the sftp-server, I would start looking at sftp.log.8239. At this point you can take a look through the logs looking for errors or you can gzip the logs and post them on the scponly mailing list for others to look at.
scponly was recently changed (in version 4.2) to not allow scp by default. To enable scponly run configure with the --enable-scp-compat flag, and then reinstall scponly using the "make; make install" process.
scp compatibility is a compile time option, and so scponly must be recompiled. Enter the folder /usr/ports/shells/scponly, and type
There are more options to choose this way, look inside the Makefile to get an overview.
'Lost Connection' typically means that either scponly has either failed to perform your request OR has deemed it unacceptable. Try turning on debugging and examining exactly what is going on.
Note that if you are upgrading scponly and get 'lost connection' when trying to transfer a file, you may need to recompile scponly with the --enable-scp-compat flag, which is now disabled by default in versions 4.2 and later.
Installing 4.8-4.1 from Ubuntu fails to recognize that libnss is a dependency. So after setting up the first scponly account, as root (which you can get to with "sudo -i", or prepend sudo to each command if you prefer):
cd /usr/share/doc/scponly/setup_chroot/ gunzip setup_chroot.sh.gz chmod 755 setup_chroot.sh ./setup_chroot.sh
Everything was correct except for the missing libnss libraries. The result was disconnections right after authorization, when the sftp-server was started, with the message
sshd[xxxx]: Received disconnect from xx.xx.xx.xx: 11: disconnected by user
This was cured by (with "scponly" here as the user's directory):
apt-get install libnss3-dev cp /lib/x86_64-linux-gnu/libnss_compat.so.2 /home/scponly/lib/x86_64-linux-gnu cp /lib/x86_64-linux-gnu/libnss_files.so.2 /home/scponly/lib/x86_64-linux-gnu chmod 755 /home/scponly/lib/x86_64-linux-gnu/*
If you're running a 32-bit version the library locations will differ.
In all likelihood this was more than necessary (probably the dev deb isn't needed just libnss3, perhaps libnss_compat.so.2 isn't needed, and the chmod was done to match the perms on the lib files put there by the script). I leave it to the next person to whittle this down, since I'm happy with the results. All of the other Debian bugs in the next section have been addressed in the Ubuntu version. If you follow the bug link in the next section, you'll see that Debian is now dropping scponly, which is unfortunate.
Here are instructions to use chrooted scponly on Debian lenny (at the time of writing, scponly is at version 4.6-1.1). You should not have the chrooted user account or his home directory created yet. Let's say you've just installed scponly with "apt-get install scponly". First enable the chrooted version:
# dpkg-reconfigure scponly
Now, to create the new user account (let's call him "upload") and the chroot jail (/home/upload) for him:
# cd /usr/share/doc/scponly/setup_chroot # gzip -d setup_chroot.sh.gz # sh setup_chroot.sh
In versions of Debian before squeeze/lenny, the setup_chroot.sh script forgets to create /dev/null inside the jail. To fix it:
# mkdir /home/upload/dev # cp -a /dev/null /home/upload/dev/
AMD64 may also need the following to work on lenny.
# mkdir /home/upload/lib64 # cp /lib/ld-linux-x86-64.so.2 /home/upload/lib64/
That should do it!
If you are using a 64-bit version of Debian before squeeze, it should be noted that Debian's setup_chroot script does not copy the necessary loader library from the lib64 directory, as it only accounts for 32-bit operating systems. Assuming your chroot is /home/upload :
# mkdir /home/upload/lib64 # cp /lib64/ld-linux-x86-64.so.2 -a /home/upload/lib64/
That should do it!
Another thing that could be missing is lib/libnss_files.so.2. This results in a message "No user found for uid NNN" given by sftp-server. This message is written to standard error and not only it is lost, but also causes sftp-server to receive SIGPIPE and abort. Assuming your chroot is /home/upload :
# cp /lib/libnss_* -av /home/upload/lib/
That should fix this particular problem.
The comments to the debian bug #556736 contain more info and an updated setup_chroot script.
The following patch fixes problems of missing libnss files from /lib and /lib64 -- it is based on patching Debian Squeeze version 4.8-4.1, but the maintainer seems to be ignoring requests to incorporate patches.
--- setup_chroot.sh 2010-02-18 19:36:53.000000000 -1000 +++ my_setup_chroot.sh 2011-04-02 00:49:06.000000000 -1000 @@ -90,9 +90,9 @@ # # TODO - i've since forgotten which OS this is for, it should be relocated to a presetup script # -/bin/ls /lib/libnss_compat* > /dev/null 2>&1 +/bin/ls /lib/libnss_* /lib64/libnss_* > /dev/null 2>&1 if [ $? -eq 0 ]; then - LIB_LIST="$LIB_LIST /lib/libnss_compat*" + LIB_LIST="$LIB_LIST /lib/libnss_* /lib64/libnss_*" fi # check that the configure options are correct for chrooted operation:
If an ls -l displays the uid and grpid, rather than the /etc/passwd and /etc/group values e.g.
sftp> ls -l drwxr-xr-x 0 123 111 96 Jun 10 13:49 . drwxr-xr-x 0 123 111 96 Jun 10 11:05 .. -rw-r--r-- 0 123 111 4 Jun 10 13:49 boo sftp> rm boo
You need libnss_files.so.2. See the next section:
On a recent CentOS (5.2 here), "sftp-server" doesn't work from scratch after you've setup your jail during the scponly install (via make jail).
During "make jail", let's say you specified /chroot/dir/ as your chroot main path, here are the next few steps you'll have to do in order to have your secure sftp access work :
- edit /chroot/dir/etc/ld.so.conf and replace its content with :
- If you are on a 64-bit system, use :
- copy /lib64/ld-linux-x86-64.so.* in /chroot/dir/lib64/
- copy /lib64/libnss_files.so.2 in /chroot/dir/usr/lib64/ (for scp and id -un)
- now type ldconfig -r /chroot/dir/
- copy /etc/group in /chroot/dir/etc/
- create the folder /chroot/dir/etc/selinux and create a file named "config" there
- insert the following content in this file :
SELINUX=disabled SELINUXTYPE=targeted SETLOCALDEFS=0
- now create the folder /chroot/dir/dev
- type mknod /chroot/dir/dev/null c 1 3
- type chmod 666 /chroot/dir/dev/null