Hello,
If you want to use the openssh server, you'll need to patch it. For more information, see:
Quite complicated process, but I think I can follow that... except that it's not really what I want either. First of all, the user would have lot's of strange dirs and files in their new home dir. It also has the same problem that the shell needs to be changed, so what happens when they login locally?
I would suggest reading the fine manual (RTFM) on this process. It is only difficult for those who probably don't have the mental capacity to administer a Linux system anyway - which since you're at least trying to do I would assume that you may. Secondly, as the documentation on the site I sent you has you set things up, the /bin /usr and other required directories are one level below the users' actual home directories, so the would not have "lot's" of strange dirs and files in their new home directory. Thirdly, as the Fine Manual says, you can statically compile any shell to work within this structure - so you could have bash, tcsh and others available for users to use. Finally, I would strongly suggest to you that you become familiar with http://www.google.com/linux if you're thinking about running Linux. Pros are likely to help you a little, but if you're not willing to even read the documentation on the links they send you, you will quickly find that you get ignored in general. There are already many great resources on the net - and google can help you find them easily. The links I sent you were from going to google and typing "chroot sftp" - and they were on the first page of the results. Also, on your security comment - I don't even how to reply to such an asinine comment. Only those who obviously do not know what they are talking about would even think that a system which was designed from the ground up as a user friendly desktop OS would be more secure than a tried and true UNIX-like variant. Just look at the CERT notifications for the past year - the numbers tell the truth. When a OS vendor embeds their own browser into my operating system and does not allow me to completely remove it from the system, then has many, many security problems with said browser, I would say that that operating system is very insecure. Not to mention that out of the box the user of the system is essentially running said browser as root! What a joke! Good luck with your attempts with learning about Linux. You can think I am a jerk for what I've said about RTFM, but if you take it to heart and actually try to find and learn things on your own, you will be much better off whether you stick with Linux or decide to go back to purchasing your software from the evil empire. BTW: All comments I make are my own, and do not reflect the opinion of my employer. -----Original Message----- From: Hugo [mailto:hg.list@gmail.com] Sent: Friday, October 22, 2004 11:17 AM To: suse-security Subject: Re: [suse-security] limiting sftp users to specific dir Hi! On Thu, 21 Oct 2004 10:23:31 -0500, James M. Patton - Contractor <mpatton@sc.army.mil> wrote:
One way would be to use the commercially available SSH server. For more information, see:
http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-linux/2001-11/000
1.html
Ah, this is exactly what I'm looking for - except that it's not free... even though they sound like it could just be downloaded from SSH.com... And this really can not be done with the OpenSSH that comes with SuSE 9.1? Another thing that bothers is that the shell needs to be set to something else... how would this affect the users that also login from the console (they should not be chrooted then, only when accessing the computer with SFTP)?
If you want to use the openssh server, you'll need to patch it. For more information, see:
Quite complicated process, but I think I can follow that... except that it's not really what I want either. First of all, the user would have lot's of strange dirs and files in their new home dir. It also has the same problem that the shell needs to be changed, so what happens when they login locally? -- HG -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here