Hi, According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem. We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access. What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)? Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem? /John
On 19/01/12 14:38, John Olsson M wrote:> Hi, > > According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem. > > We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access. > > What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)? > > Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem? > > > /JohnPlace a couple of wrappers around the commands, doing the chroot for you?
On Jan 19, 2012, at 7:38 AM, John Olsson M wrote:> Hi, > > According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem. > > We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access. > > What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)? > > Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem?What you really want is for someone to extend: Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file. The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5). So it can be used to support Subsystem. e.g. Match Subsystem sftp ChrootDirectory /path/to/chroot/ Which of course it doesn't at this point. But I can see it being a very useful addition in cases where you want new subsystem be limited in the drive exposure. Mind you like all things it isn't perfect if you allow something that is a real shell, but like with all tools one has to understand how to deploy them. - Ben