Topic: [Solved] SFTP does not chroot user to iBay

[LANMonkey]

I am enabling FTP access for a website administrator using the guidlines I found here:

http://wiki.contribs.org/FTP_Access_to_Ibays

In confronting a problem with an FTP client, I tried using SFTP instead and found that the user is no longer being directed to the chroot specified in Security->Remote Access.  It looks like the user under SFTP has access to the whole drive from the root on down.  I also noticed that it appears that it is necessary to allow SSH access to this user to make SFTP work.

I've also seen the contribs article on SFTP here:

http://wiki.contribs.org/SFTP

Why is the user no longer being chroot-ed to the directory I want?  And also, why is the CGI directory not a chroot option?  That is precisely the directory I need.

(This is the client problem that led me here, but I'll mention it here any way:

I am running a trial version of OptiPerl, Perl development software available here, http://www.xarka.com/optiperl/.  One of its features is being able to create remote sessions and browse remote files using FTP/SFTP.  I am seeing some unusual behavior.  With my web admin user, I try to access the user's iBay as established in the Remote Access, so the chroot is /MyiBay.  I find that the client is able to connect and upload the contents of that directory according to the logs, but I can't see it in the window used to display what you find.  However, if I set the chroot to one of the folders in iBay directory, like /MyiBay/html, then I can see the contents.

Is there anything in SME that might be causing the problem?  It's not a problem I am seeing in any other client.)

But again, my main reason for posting here is the chroot problem, any and all tips or clues on this would be appreciated.

[Stefano]

Lanmonkey: please search the forums before posting, your question has been asked many times

atm this is unsupported by SME

please read here

HTH

[LANMonkey]

I did search the forums for "sftp chroot" and didn't find anything helpful.  The link you provided wasn't very clear either.

And finally, "atm this is unsupported by SME" requires some interpretation as well.  What is "atm"?  And also ... "unsupported"?

It seems a little strange that when you use FTP, everything works as advertised in the contribs.  But if you use SFTP, suddenly you have access to the whole drive from the root on down.  Why is it with the additional security of SFTP, suddenly the whole point of the remote access controls becomes entirely defeated?  It looks like something is broken, not "unsupported".

Does anyone have any clues about my client problem?

[Daniel B.]

No, there's nothing broken.

SFTP is not secure FTP (which is FTPS), it's another protocole which usually uses SSH. Chrooting SFTP is very complex with the openssh version on SME, only very recent openssh version allow painless chrooting. That's why what you want is not broken, but unsupported.

Regards, Daniel

[LANMonkey]

OK, thanks.  That settles it.

[Stefano]

I did search the forums for "sftp chroot" and didn't find anything helpful.  The link you provided wasn't very clear either.

in the bug I linked you can find how to upgrade (at your own risk) openssh and hot to modify its conf file to create a chroot

And finally, "atm this is unsupported by SME" requires some interpretation as well.  What is "atm"?  And also ... "unsupported"?

well..

atm=At This Moment
unsupported means that you could achieve the result (see above), but there's no support by the community or the devs for it

It seems a little strange that when you use FTP, everything works as advertised in the contribs.  But if you use SFTP, suddenly you have access to the whole drive from the root on down.  Why is it with the additional security of SFTP, suddenly the whole point of the remote access controls becomes entirely defeated?  It looks like something is broken, not "unsupported".

Does anyone have any clues about my client problem?

see Daniel's answer

[CharlieBrady]

But if you use SFTP, suddenly you have access to the whole drive from the root on down.

No, this is not true. Access is controlled via linux file system permissions. You will have no access to /root, for instance.

Observation: I have never understood the amount of energy which goes into chroot FTP access.

Why is it with the additional security of SFTP, suddenly the whole point of the remote access controls becomes entirely defeated?

The additional security of SFTP over FTP relate to transport and authentication security, not access control to directories and files.