Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Faq

wytcld edited this page · 3 revisions

Table of Contents

Scponly isn't working, what do I do?

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.

How do I turn on logging?

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 scpuser@10.x.x.x:incoming/
scpuser@10.x.x.x's password:
scponly[8253]: chrooted binary in place, will chroot()
scponly[8253]: 3 arguments in total.
scponly[8253]:  arg 0 is scponlyc
scponly[8253]:  arg 1 is -c
scponly[8253]:  arg 2 is scp -t incoming/
scponly[8253]: opened log at LOG_AUTHPRIV, opts 0x00000029
scponly[8253]: retrieved home directory of "/home/ftpusers/scpuser" for 
user "scpuser"
scponly[8253]: chrooting to dir: "/home/ftpusers/scpuser"
scponly[8253]: chdiring to dir: "/"
scponly[8253]: setting uid to 504
scponly[8253]: processing request: "scp -t incoming/"
scponly[8253]: denied request: scp -t incoming/ [username: scpuser(504), 
IP/port: ::ffff:10.y.y.y 56642 22]
lost connection

I still can't find my problem, what else can I try?

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

[prompts]

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.

I can't connect to scponly using scp, what do I do?

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.

How can I enable scp compatibility in the FreeBSD Port of scponly?

scp compatibility is a compile time option, and so scponly must be recompiled. Enter the folder /usr/ports/shells/scponly, and type

 make WITH_SCPONLY_SCP=yes

There are more options to choose this way, look inside the Makefile to get an overview.

What does "lost connection" mean?

'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.

Chroot and Ubuntu 11.10

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.

Chroot and Debian

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:

User and Group names not appearing in SFTP listings

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:

Chroot and CentOS 5.x

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 :
 /lib
 /usr/lib
  • If you are on a 64-bit system, use :
 /lib64
 /usr/lib64
  • 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
And there you are.
Something went wrong with that request. Please try again.