I just installed and configured Cygwin SSH on a Windows2003 DC. We want
to have external clients be able to sftp into this server and be able
to upload and download files from a single particular directory. But
when I test this functionality I can connect to the server and am
dumped into the correct dirctory but I can then uplevel to the cygwin
root directory and have access to everything there. I have searched
quite a bit for a solution and have found nothing, except for
references to chroot which apparently can only be configured on a pure
unix machine. It is puzzleing to me that more businesses would not need
this functionality, and what is the point of secure ftp if you cannot
lock your users into there home directory. Does anyone know of a better
free solution?
My passwd file looks like this:

sally:unused_by_nt/2000/xp:11118:10513:sally,U-DSDNET\sally,S-1-5-21-838629778-670936772-3974172153-1118:
/data:/usr/sbin/sftp-server

Thanks.

"tilopa" <wgilgallon@gmail.com> writes:

> I just installed and configured Cygwin SSH on a Windows2003 DC. We want
> to have external clients be able to sftp into this server and be able
> to upload and download files from a single particular directory. But
> when I test this functionality I can connect to the server and am
> dumped into the correct dirctory but I can then uplevel to the cygwin
> root directory and have access to everything there. I have searched
> quite a bit for a solution and have found nothing, except for
> references to chroot which apparently can only be configured on a pure
> unix machine. It is puzzleing to me that more businesses would not need
> this functionality, and what is the point of secure ftp if you cannot
> lock your users into there home directory. Does anyone know of a better
> free solution?

Ironically, it's the non-free operating system you're using
unfortunately is what's thwarting you it seems. :-)

But VanDyke's Vshell server may be worth the money if you can't get
where you wanna go with the free stuff
http://vandyke.com/products/vshell/index.html

Or... and this is kinky, and an idea off the top of my head, Vmware
Server http://www.vmware.com/products/server/ is free, and rocks. Use
it create a Linux virtual machine on that DC. Then, you can run
openssh on linux properly. A drive share can be made to cross the
virtual machine boundary if need be. Samba has PAM modules evidently
to allow to either auth against the 2003 DC directly, or to keep those
passwords in sync if the samba section of
http://www.kernel.org/pub/linux/libs/pam/modules.html is to be
believed.

And if someone hacks your ftp server, they're inside a virtual machine
jail by and large only with access to the windows 2003 directory you
specifically shared into the virtual machine.

But by the time you're done with that you may really wish you had
spent the money for vshell server. :-)

Best Regards,
--
Todd H.
http://www.toddh.net/

"tilopa" <wgilgallon@gmail.com> writes:

> I just installed and configured Cygwin SSH on a Windows2003 DC. We want
> to have external clients be able to sftp into this server and be able
> to upload and download files from a single particular directory. But
> when I test this functionality I can connect to the server and am
> dumped into the correct dirctory but I can then uplevel to the cygwin
> root directory and have access to everything there. I have searched
> quite a bit for a solution and have found nothing, except for
> references to chroot which apparently can only be configured on a pure
> unix machine. It is puzzleing to me that more businesses would not need
> this functionality, and what is the point of secure ftp if you cannot
> lock your users into there home directory. Does anyone know of a better
> free solution?

Well ... is this functionnality really important to you ?
Files have permissions, so you can limit the users rights. I suppose you
can just modify the read, write and execution right on the various place
where you don't want access (and maybe use a different group for remote
users).

The point of secure ftp is to do secure authenticated file transmission,
not to limit users ... the os handle users and the limits (and cygwin
can handle some kind of limitations, but I would not trust such thing).

And most businesses just setup a unix/linux box to do this kind of
things (that is for the category 'better free solution')

--
Thomas Samson
Computers are like air conditioners. Both stop working, if you open
windows.
-- Adam Heath

Thomas Samson wrote:
> "tilopa" <wgilgallon@gmail.com> writes:
>
> > I just installed and configured Cygwin SSH on a Windows2003 DC. We want
> > to have external clients be able to sftp into this server and be able
> > to upload and download files from a single particular directory. But
> > when I test this functionality I can connect to the server and am
> > dumped into the correct dirctory but I can then uplevel to the cygwin
> > root directory and have access to everything there. I have searched
> > quite a bit for a solution and have found nothing, except for
> > references to chroot which apparently can only be configured on a pure
> > unix machine. It is puzzleing to me that more businesses would not need
> > this functionality, and what is the point of secure ftp if you cannot
> > lock your users into there home directory. Does anyone know of a better
> > free solution?
>
> Well ... is this functionnality really important to you ?
> Files have permissions, so you can limit the users rights. I suppose you
> can just modify the read, write and execution right on the various place
> where you don't want access (and maybe use a different group for remote
> users).
>
> The point of secure ftp is to do secure authenticated file transmission,
> not to limit users ... the os handle users and the limits (and cygwin
> can handle some kind of limitations, but I would not trust such thing).
>
> And most businesses just setup a unix/linux box to do this kind of
> things (that is for the category 'better free solution')
>
> --
> Thomas Samson

Thomas and Todd thanks for the response,

I guess I can live with the Cygwin limitation for now, and you are
right it is a Windows limitation ultimately, and least they only have
read permission and cannot really access the root directory. I have
thought about the virtual machine solution, but it somehow does not
seem like a good idea for a production machine, I don't think my
manager would buy it anyway. What I really want to do is a straight
linux box configured with sftp and connect users to my windows dirctory
with samba and pam_ldap and whatever else I need, but I don't have the
time to figure it out for this project. I'll put it togethor for a
solution for future clients. I guess part of my frustration is that I
did not take the time when I had the chance in the past to really learn
Unix, and now I am sorry I did not.
Thanks again for your .

"tilopa" <wgilgallon@gmail.com> writes:

> I guess I can live with the Cygwin limitation for now, and you are
> right it is a Windows limitation ultimately, and least they only have
> read permission and cannot really access the root directory. I have
> thought about the virtual machine solution, but it somehow does not
> seem like a good idea for a production machine,

There are a lot of production heavy hitters using Vmware ESX Server
for vitualization.

The free VMWare Server product was formerly their GSX Server product
which also got used in production environments. They're remarkably
robust though I agree that it seems a little icky at first blush.

> I don't think my manager would buy it anyway.

> What I really want to do is a straight linux box configured with
> sftp and connect users to my windows dirctory with samba and
> pam_ldap and whatever else I need, but I don't have the time to
> figure it out for this project. I'll put it togethor for a solution
> for future clients. I guess part of my frustration is that I did not
> take the time when I had the chance in the past to really learn
> Unix, and now I am sorry I did not. Thanks again for your .

All that sounds like a hell of a cost justification for VanDyke VShell
Server :-)

If the manager can give you more time than money, then the VMWare
Server + Linux approach would be the way to go, but you'd want someone
with that experience to you with questions, which may cost a
little money too.

Best Regards,
--
Todd H.
http://www.toddh.net/

Todd H. wrote:
> "tilopa" <wgilgallon@gmail.com> writes:
>
> > I guess I can live with the Cygwin limitation for now, and you are
> > right it is a Windows limitation ultimately, and least they only have
> > read permission and cannot really access the root directory. I have
> > thought about the virtual machine solution, but it somehow does not
> > seem like a good idea for a production machine,
>
> There are a lot of production heavy hitters using Vmware ESX Server
> for vitualization.
>
> The free VMWare Server product was formerly their GSX Server product
> which also got used in production environments. They're remarkably
> robust though I agree that it seems a little icky at first blush.
>
> > I don't think my manager would buy it anyway.
>
> > What I really want to do is a straight linux box configured with
> > sftp and connect users to my windows dirctory with samba and
> > pam_ldap and whatever else I need, but I don't have the time to
> > figure it out for this project. I'll put it togethor for a solution
> > for future clients. I guess part of my frustration is that I did not
> > take the time when I had the chance in the past to really learn
> > Unix, and now I am sorry I did not. Thanks again for your .
>
> All that sounds like a hell of a cost justification for VanDyke VShell
> Server :-)
>
> If the manager can give you more time than money, then the VMWare
> Server + Linux approach would be the way to go, but you'd want someone
> with that experience to you with questions, which may cost a
> little money too.
>
> Best Regards,

Todd,
I am looking into Vschell. It seems reasonably priced and better for
what we are looking for than WS-Ftp (which we did not like because it
only has SSL) and about the same price. I'll download the eval and
check it out.
Thanks again.
> --
> Todd H.
> http://www.toddh.net/