ChrootDirectory per SSH Subsystem?

John Olsson M john.m.olsson at ericsson.com
Fri Jan 20 18:29:46 EST 2012


> What you really want is for someone to extend:
>
>     Match   Introduces a conditional block.
--snip--
> 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.

Yes! That is exactly what I was looking for. :)

Before diving into the source code and trying to figure out how to accomplish that does anyone have any feeling for the size of such an undertaking? Anything special one should consider/have in mind when implementing it?


> 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.

I agree with you 100% here. :)


/John

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at offwriting.org] 
Sent: den 19 januari 2012 23:01
To: John Olsson M
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: ChrootDirectory per SSH Subsystem?


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 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.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.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




More information about the openssh-unix-dev mailing list