On Mon, Jun 2, 2014 at 1:17 AM, daggs <daggs@xxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
