Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I imagine many of you have production environments and the option for recompiling a software package like OpenSSH, that is widely use is not an option, at least all the time. The solution in Securing SFTP requires you to rebuild OpenSSH at least for CentOS_5.1.

I was hoping to get another way of preventing my end-users (using sftp) not to see other directories other than their allowed folder. Similar to isolation mode in Windows FTP server.

After various google searches I thought about looking here, but nothing I found other than the post above. Any ideas?

share|improve this question
Link referenced --> – Dave K May 28 '09 at 13:48
  • OpenSSH supports conditional configuration based on user, group, or address
  • OpenSSH also has an integrated sftp server that does not depend on the chroot for configuration, libraries, ...

This method requires no extra maintenance for the chroot!

It is also more secure because no executables or libraries are required inside the jail.

Append this to your sshd_config:

Match Group mysftpgroup
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no

Users in the mysftpgroup UNIX group should then not be able to use any other SSH service than SFTP. Of course, verify this for your specific configuration!

Note that a Match ‘section’ is terminated by either a new Match section or the end of the configuration file. See man sshd_config for other options. Googling the man page might yield an outdated version.

share|improve this answer
this is the right answer. the OP was likely referencing outdated information within regard to the fact that at tone time Chroot was not integrated into the main code base for OpenSSH. this has not been the fact for quite a long time now. – RapidWebs Jun 23 '14 at 4:47

If I've got your question right then you can do this from with the config files. See this ServerFault question for some help setting up chroot in the config. The OpenSSH suite of tools has seen some really nice options lately available in the configs. It's well worth your time to read the manuals and the FAQ, even if you've read them thoroughly a year or two ago.

When do you ever need to recompile OpenSSH to get security? OpenSSH's track record for security is something other projects (even security related ones) can only dream about. Beware of patches from third parties thinking they're going to improve security in OpenSSH. Don't forget Debian's goof.

share|improve this answer

Restricting access for SFTP users should not require re-compiling openssh.

You should be able to set your home directory permissions and umask such that a user can only see his own home directory.

Of course, users will be able to see (but not modify) many system files as well. If you are wanting to restrict even this, I think you can make sftp sessions run in a jail.

share|improve this answer

I realize that you went with Vshell, but I've had pretty good luck using scponly. Not sure about CentOS, but there is a debian package that's pretty easy to get going:

sudo aptitude install scponly
sudo dpkg-reconfigure scponly
cd /usr/share/doc/scponly/setup_chroot/
sudo gunzip
sudo chmod +x
sudo ./ #this creates the user and home dir
mkdir /home/<user>/dev
mknod -m 666 /home/<user>/dev/null c 1 3 #apparently there's a bug in
share|improve this answer

I think you are talking about two different kinds of security here.

The first one, which does require recompilation (or installation of a packaged binary) is end-to-end communication security. Anything you do on the server with regards to files/folders a user can access will not secure the communications between the client-server. Actually, if you do not keep Openssh up to date, there is a possibility that someone could use this as an attack vector to get into your server.

The second is file/folder security. You can restrict the folder settings (chroot, or isolation mode) and this will restrict the files that can be accessed by the logged in user. Note that this does not help to secure the actual communications of the files.

Hope that helps!

share|improve this answer
Thanks for your feedback. Our production environments are updated with the packaging system like yum or up2date. Our SSH version is OpenSSH_4.3p2 and we also have some servers in 3.9. My understanding is that in order to allow isolation for SFTP i need OpenSSH5.1 or up. I hope this clarifies a little. – Geo May 28 '09 at 14:54

What you're looking for is a chroot, aka jail. The setup can be somewhat complex, and it's unlikely the tools required exist in package form in the default CentOS repos. However, here's a debian tutorial I've used before, it should put you on the right track:

share|improve this answer
Thanks alex, but our requirements will require our servers to provide a chroot per server which will probably be very high maintenance. – Geo May 28 '09 at 17:00
up vote 0 down vote accepted

I try to got open source before recommending or even considering a paid software version. I am by no mean related to this recommendation, is only based on my needs. I spent too much time trying to find the right solution for my requirements. The options I tried was:

  • Installing OpenSSH 4.9 or higher which did not work that well for many technical reasons.
  • rssh from
  • jailkit
  • and the Debian tutorial mentioned here.

I am sure all the above solutions work fine, but they did not met my requirements for this project. One that is not free is the Vshell Server from VanDyke. It was easy to install (at least the evaluation version) and super-easy to setup chroot access to my users.

Now my sftp or scp users will only see their home directory and they will not be able to execute anything. It is easy to maintain just add users to a group and assign them a home directory.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.