On Fri, Sep 11, 2009 at 04:42:57PM -0400, John Chatelle wrote:
> The chroot jail with `scp' works, but sftp doesn't, and for the life of me, 
> I can't figure out why.
[...]
> Could not chdir to home directory /insco_test: No such file or directory
[...]
> If I create the directory /insco_test, the file goes to the right place:
>  /usr/medent/users/insco_test which is within the chroot jail, so the client 
> error
>   "Could not chdir..." is a red herring.

I don't think it is, and I think the fact that sftp-server can not cd
into this directory could be the root cause of your problem (though,
possibly not).  From the man page for rssh.conf:

  If  the  user’s  home directory (as specified in /etc/passwd) is
  underneath the path specified by this keyword, then the user will be
  chdir’d into their home directory.  If it is not,  then  they  will
  be chdir’d to the root of the chroot jail.

In other words, if /insco_test is under /usr/medent/users (it's not,
it's under /), then the user will be put there.  Since it's not, the
user is put in /.

You say that it works for scp... that's because your scp command
specified the target directory, which is evaluated and correct *after*
the chroot() call.  IIRC (and to be honest I'm too lazy to look at the
code to confirm) I'm almost positive that the chdir() call happens
before the chroot() call, so you're trying to cd into the system's
absolute /insco_test, which does not exist.  I'm guessing that
sftp-server is bailing because it finds itself in what is (after the
chroot() call) the root directory, and the user has no permissions
there.  But that part's just a guess, since there's nothing in the
logs you posted to indicate why the read failed... just that it did.

>   Uncommented lines in /etc/rssh.conf are:
> logfacility = LOG_USER
> allowscp
> allowsftp
> umask = 022
> chrootpath = "/usr/medent/users"
> user=insco_test:011:00011:"/usr/medent/users"  # both with chroot
>  the pertinent line in my  password file are:
> insco_test:x:734:501::/insco_test:/usr/bin/rssh

This is "wrong" -- it doesn't do what you seem to think it does.  You
need to change the home directory to /usr/medent/users/insco_test.  I
bet it will work after that.

> [pid 29485] close(3)                    = -1 EBADF (Bad file descriptor)^M
> [pid 29485] close(4)                    = 0^M
> [pid 29485] close(5)                    = 0^M
> [pid 29485] close(6)                    = 0^M
> [pid 29485] close(7)                    = 0^M
> [pid 29485] close(8)                    = -1 EBADF (Bad file descriptor)^M
> [pid 29485] close(9)                    = 0^M
> [pid 29485] close(10)                   = -1 EBADF (Bad file descriptor)^M

This is totally normal behavior for a server, and should not be causing your
problem.  Most servers close all open file descriptors other than 0-2,
to make sure that any files open by its parent are not open in the
child, which can cause problems in some circumstances.  However, this
could be concerning:

> debug1: subsystem: exec()
> /usr/medent/users/usr/libexec/openssh/sftp-server -
> l VERBOSE
> debug2: fd 3 setting TCP_NODELAY
> debug2: fd 8 setting O_NONBLOCK
> debug3: fd 8 is O_NONBLOCK
> debug2: channel 0: read<=0 rfd 8 len 0
> debug2: channel 0: read failed
> debug2: channel 0: close_read

But it's not clear to me if the fd lines are from the parent (sshd)
for from the child (sftp-server).  If it's from the child, then it's
odd... because the child should be doing all of its communication via
stdin/stdout/stderr (i.e. fd's 0-2).  If this actually *is* the
problem, then it's a bug in the version of OpenSSH you compiled, or
possibly you didn't configure it properly.  You'd be best off using
the version supplied by your vendor (i.e. CentOS).

Another possibility is that your sftp-server binary has the wrong
permissions (e.g. it was not executable after you ran make install, or
after you copied it manually, whichever).  

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

Attachment: pgpMoiiG8wXAo.pgp
Description: PGP signature

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
rssh-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rssh-discuss

Reply via email to