sftp session disconnects right after passwd enter

[Nico Kadel-Garcia]

On Mon, Jun 2, 2014 at 1:17 AM, daggs <daggs at gmx.com> wrote:

> you are both correct, the first bug was that the path given to the binary didn't exists, after changing it to the correct path, I was able to connect without the chrootdirectory defined.
> but it seems that chrootdirectory can be used only with internal-sftp so I've modified it and it works.
>
> I do wonder why chrootdirectory can work only with internal-sftp
>
> thanks to all of the help.

Chroot cages are tricky. To use the specified binary, the full set of
libraries and "devices" would have to be available in the chroot cage,
at least as implemented in OpenSSH. It's also why the usernames and
group memberships don't show up for the chrooted clients unless there
is a copy of /etc/passwd and /etc/group in the chroot subdirectory
with the relevant user and group entries. The chrooted programs are
really, rally not supposed to be able to reach outside of that chroot
cage for *any* other filesystem based resources.

It's not an absolute protection: look up "chroot cage breaking" for
examples of how people have historically escaped the cage. But I've
found it to be a useful restriction to prevent casual system browsing
by people I do *not* want looking at other user's home directories or
system contents.

Unfortunately, I also find the restrictions for SFTP to be burdensome.
To set up multiple chroot cages for multiple users, one has to either
make user specific sshd_config settings, or provide a "shared" top
level root owned chroot cage that breaks the user isolation that is
part of the whole point of chroot cages. That's why I use vsftpd and
FTPS, instead. While it may not be as robustly built as OpenSSH's SFTP
chroot, it's one heck of a lot easier to manage and configure, and can
play very nicely in environments where people also have shell access.