Here's what I'd like to do:

(1) Eliminate the need for FTP by replacing it with SFTP / SCP, and
(2) Preserve some of the useful functionality that VSFTPD has, such as the simplicity of its chroot configuration file.

I installed rssh on my system to limit users to SFTP / SCP, but of course, they aren't chroot'd to their home directory any longer like in plaintext FTP.

How can I restrict a user to their home directory, while at the same time force them to use SFTP or SCP? Even if I could pull off the chroot and give them SSH access, that would be okay. My main concerns are that they use a secure connetion, and that they're limited to their home dir.

Would this involve compiling OpenSSH from source with some options? I've been using RedHat's RPMs for OpenSSH but compile plenty of programs, so if that's what it'll take, I'd be willing to try. Anyone have any suggestions? Thanks!

Rssh-2.0.2 comes with chroot facility, else you could try patching OpenSSH with the chroot patch from http://chrootssh.sourceforge.net or http://mail.incredimail.com/howto/openssh/ if you're not comfortable with setting up a chrooted jail with apps like pam_chroot, jail or chrootjail.

I've patched OpenSSH-3.5p1 with the patch from chrootssh.sourceforge.net w/o probs. The patch is rather small so I don't think patching the newest OpenSSH-3.6p1 would be a problem as well.

Restricting users to use SFTP or SCP means just not providing ftp services (and not allowing them to run their own).

If you need more docs on chrooting check the 1st thread in this forum, post #4.

Thanks for the information. How do I chroot rssh? I see a file called rssh_chroot_helper but setting that as the user's shell makes them unable to log in...

Please post facts, like how you've configured it, what you've done (following the instructions from the rssh chroot doc), what you tried to resolve your issues and what errors you got.

I compiled rssh from source on my Linux machine, and I'm currently running OpenSSH installed via RedHat's RPM. In order to chroot rssh, do I need to also chroot OpenSSH? What I was looking for is some kind of simpler functionality, such as the configuration file that vsftpd uses, to quickly restrict a user to their home directory. Is that possible?

Maybe with patching it's possible but there is currently no other way to chroot on a per user base!

Maybe with patching it's possible but there is currently no other way to chroot on a per user base!
AFAIK OpenSSH depends, if you compile it that way, on PAM, so you could use pam_chroot for instance. If not, then it'll default to using /etc/passwd info. I you set the "jail" binary (or any chroot providing app), it should be able to use that. Patching OpenSSH could make it "easier" (to administer) because now the app itself handles chrooting.

I compiled rssh from source on my Linux machine, and I'm currently running OpenSSH installed via RedHat's RPM. In order to chroot rssh, do I need to also chroot OpenSSH?
No: see "man 5 rssh.conf" and Google for "ssh and +"privilege separation"". Please tell us what you didn't understand from reading the rssh-2.0.2 docs or the other directions already given.

What I was looking for is some kind of simpler functionality..()
Aw, cummon, shouldn't be that hard...

I must have missed that configuration file when it was installed; things make a little more sense now instead of the binary "magically" running without a config file

The docs all make sense. I guess my main question is whether or not you can use rssh to chroot on a per user basis. If I recall correctly, it said on the website (http://www.pizzashack.org) that it would be supported in a later version.

Thanks for your help; apologies if my posts weren't detailed enough for you make sense of.

Thanks for your help; apologies if my posts weren't detailed enough for you make sense of.

Np, that's what we're here for, and no need to apologize.
It's not the fact your posts where or wheren't detailed enough, but more that I like to (try to) focus you on having a methodical approach towards troubleshooting. Once you get a grip on the basics, like reading them docs first, knowing how to look for dependencies, what the generic ways of configuring stuff are and how to extract usefull (error) output, then it will generally be easier for you to "classify" your problems, which will make it easier for you to present your problems in a more efficient* way, which will make it easier for those who try to help you solve your problems. IMNSHO having a methodical approach to troubleshooting will save you time, any time.

*A posted problem should contain (at least an attempt at providing):
1. app +version, configuration files,
2. (ordered) list of actions taken, fixes tried, logfiles and error logs,
3. (clear!) questions.

The best threads I've seen start off with replies asking for details the poster didn't provide, just to make sure they got the scope of the problem right, finding dependencies, regular errors, etc etc, gradually building up towards finding a workaround or solution. To me those threads are a pleasure to read and show the real "power" that LQ has...