[PATCH] sftp-server Restricted Access

[Dan Peterson]

On Sun, 25 Jun 2006, Damien Miller wrote:

> Julien Demoor wrote:
>> Hello,
>>
>> This patch makes it possible to restrict sftp sessions to a certain
>> subtree of the file system on a per-Unix account basis.
>
> There has been a similar patch in bugzilla for a while:
>
> http://bugzilla.mindrot.org/attachment.cgi?id=586
>
> I'm looking at adding the ability to specify commandline arguments to 
> SubSystem declarations in sshd_config, but it is a little fiddly as any 
> change has to gracefully cope with forced commands in authorized_keys 
> files as well as the fairly common practice of making sftp-only accounts 
> by making sftp-server the user's login shell.
>
> It will be easier when Darren's "Match" stuff is done, because we can
> reuse it to do forced-commands in sshd_config.

Can you expand on "forced-commands in sshd_config" a bit?

I'm curious, because I'm wondering if it might be able replace the custom 
changes I've made....

I recently added support for authorized_keys via GSSAPI/Kerberos 
authentication... mainly so I could use the "command=" option.  Then, I 
realized, for my purpose, it would be better to just have a global 
"ForcedCommand" defined in sshd_config, so I added that as well.

My reason for doing this is because I'm running sshd on a non-standard 
port for CVS/Subversion access.  My ForcedCommand makes sure that only 
CVS/Subversion related commands can be run.

A couple of problems I ran into with the global forced command...

   1) I had to add an sshd_config option to ignore the user's login shell 
when exec'ing the forced command.  The problem here is that the user's 
login shell could be something like "/bin/false".  If this option is set, 
then I simply exec the forced command directly, rather then via the login 
shell.

   2) I also had to add an sshd_config option to ignore the user's home 
directory.  In my case, these same user's with a login shell of /bin/false 
(which is the majority of users) don't have a real home directory either.