I've updated and modified some older OpenSSH chroot tools to work correctly with OpenSSH 3.1p1. I'd like to get them integrated into the code base, in strong preference to that ghods-awful "chroot" shell scripting done by ssh-3.x. The patch modifies OpenSSH to do a chroot to the part of any $HOMEDIR which contains the characters '/./', to the directory location preceeding that set of characters. The chroot tarball building tool is designed to grab the user-selected shell, ssh, and another other selected components along with the required dynamic libraries to allow those tools function.
chroot would be nice to have, but having sshd chroot for /./ in $HOME is not a standard behaviour.
Well, it wasn't my original idea, I'm just trying to get it implemented cleanly. It's not "common behavior" for rather different chroot environments, such as the limited environment of ftpd. That works for anonymous ftpd logins because the ftpd remains present as the user's interactive shell, interpreting their commands. To do this for OpenSSH, sshd or something like it would have to be use some kind of restricted shell, maintained and forked off, and it would prohibit local user login. By using the "/./" as a flag for the local user, the chroot behavior remains under root control, the user can use any shell the admin is willing to install for them, and once can even created shared environments as follows. nkadel:*:1000:1000:Shared SSH chroot for Nico:/home/shared/./../nkadel:/bin/bash If I log in locally, or look for my email, I wind up in /home/nkadel. If I come in via SSH, I wind up in /home/shared. This as opposed to: nkadel2:*:1000:1000:chroot SSH for Nico:/home/nkadel/./:/bin/bash For this, I'd wind up in /home/nkadel in a chroot cage. Does this make sense? I'd welcome better ideas.
I am wondering if a patch, or something like it, will end up in the mainline openssh source tree? I found http://chrootssh.sourceforge.net/ and then went looking to see if that patch was made and found this bug. I'm just wanting to set up a chroot() jail to accomplish with sftp/scp and rsync/cvs over SSH what we now get with many ftpd's.
I saw other chroot bugs were marked as WONTFIX. Why do you refuse adding chroot to openssh? SCP is a secure alternative to FTP, but doesn't have chroot as most of FTP servers do. This project is up to date http://chrootssh.sourceforge.net/ Thank you
Created attachment 683 [details] Chroot patch for openssh-3.8p1 I have looked at the proposed patch and found it very strange. For what it is worth, here is a patch based on SSH2's ChRootUsers sshd configuration option. Of course, you will need to add system files such as /dev/ttys and /lib to each user account but that is exactly what I needed in order to control the user's environment. See page 185 of Barrett and Silverman's O'Reilly SSH book.
Created attachment 1018 [details] A patch to provide chroot functionality to sftp-server The patch is taken from http://mail.incredimail.com/howto/openssh/addons/sftp-chroot.diff It allows to setup sftp-server for an user without putting any libs into the chroot, using the described "magic /./" to enable it and define the chroot directory (within the home directory).
Please see bug #474 for a patch against CVS -current
Created attachment 1156 [details] sftp chroot patch for OpenSSH -current 2006/07/06+ This patch adds chroot support for sftp-server. It won't be committed until better sshd_config support for enabling it is ready, because it is still too easy for people to activate it in a way that is easy to circumvent or that creates new holes
remove URL, it is dead.
What about using PAM for sftp-server? Currently, as it seems, only /etc/pam.d/ssh gets used (also for the sftp subsystem), but I thought that it would be a nice idea to use /etc/pam.d/sftp-server instead, if it is available. This way, you could use session required pam_chroot.so in /etc/pam.d/sftp-server and it would chroot to the path given in /etc/security/chroot.conf from within sftp-server (and therefor should also not require to have any libs in each chroot). Does this sound reasonable? Should I open a new tracker wish item for that?
Created attachment 1206 [details] Updated patch Patch updated to -current as of November 9th 2006. Same caveats that I mentioned previously apply.
(In reply to comment #11) So far, this is the best solution I have seen to the SFTP chroot problem. I would love to see it officially implemented, but may begin using it on a production system long before that. However, I would like to know what the potential risks are and would also like to help eliminate them if I can. So far, the only serious issue I've found is that tilde expansion done by the shell uses the $HOME environment variable, which can of course be set in .ssh/environment . If I can be of any help in addressing this or other issues, please let me know.
Created attachment 1277 [details] Pre-shell tilde expantion proof-of-concept hack (In reply to comment #12) > So far, the only serious issue I've found is that tilde expansion > done by the shell uses the $HOME environment variable, which can of > course be set in .ssh/environment . In light of this, would it be appropriate for sshd to expand a tilde in a subsystem argument before passing it to the shell? A kludgy proof-of-concept hack is attached.
Created attachment 1346 [details] Updated chroot patch for OpenSSH 4.7_p1 Revision 1.73 of sftp-server.c is slightly incompatible with the previous path. This tweaked one works with it.
A newer version of the patch attached to bug #1352 has just been committed, with additional support for an in-process sftp-server to avoid the need to configure the chroot with support files. This will be in openssh-4.8.
Fix shipped in 4.9/4.9p1 release.
Out of curiosity, could you summarize the reasons that the sftp-server level chrooting was discarded in favor of sshd ChrootDirectory? At first look it seems better to have a small sftp-server process running than the full blown sshd, to provide this functionality. Thanks in advance.
Huh? You need sshd running anyway.
I guess I was not clear. Why have the sftp-server embedded, risking bugs in the full blown sshd code, and not just fork the simple sftp-server and perform the chroot there (like your patch in this bug does)? What were the reasons the first solution was prefered? In the first comments you mention some things but I don't quite understand.
As far as I can tell, ChrootDirectory does not allow per-user chrooting to "empty jails" (e.g. home directories) such as this bug's patch does (and modern FTP servers). So from my perspective this bug isn't resolved. Should it be reopened, or should I submit a new bug/feature request? Thanks.
No, ChrootDirectory can be set per-user using the sshd_config(5) Match option and may be used to chroot users into empty jails for sftp use.
(In reply to comment #21) > No, ChrootDirectory can be set per-user using the sshd_config(5) Match > option and may be used to chroot users into empty jails for sftp use. Yes, but since the directory has to be owned by root, then users can't write to their home directory, correct?