I've followed a half-dozen different tutorials on setting up chroot for sftp users, but my jailed users can still browse up into parent directories. I suspect my permissions aren't set up correctly, because this is the part that varies the most between the tutorials. Here's what I've done so far:

1) I'm using CentOS 5.6, where the default OpenSSH is version 4.3, so I manually installed the latest 5.x version. Running sshd -v now returns OpenSSH_5.9p1, OpenSSL 0.9.8e-fips-rhel5.

2) I edited /etc/ssh/sshd_config to change Subsystem sftp to internal-sftp, and added:

Match user guest
ChrootDirectory %h
X11Forwarding no    
AllowTcpForwarding no
ForceCommand internal-sftp

3) Restarted sshd.

4) Created a user "guest" with home directory /var/www/uploads/guest.

5) /var/www/uploads is owned by root:root with mode 755.

6) /var/www/uploads/guest is owned by guest:root with mode 755.

Using the Transmit sftp client on my Mac, I logged in with the guest user. It opens the user's home directory by default, but I can then navigate up the directory levels and browse other directories on the server.

Some tutorials say /var/www/uploads should have mode 700 or 750; if I do this, I can still log in as the guest user, but I see the server root directory by default and can browse all other directories.

Other tutorials say I should change the guest user's shell to /bin/false; if I do this, I can't log in as the guest user at all. Transmit says "The user name or password was not accepted by the server" and the command-line sftp client says "Connection closed" after I enter the password.

I think I've tried everything -- can someone see what's missing?


Looks like the ChrootDirectory should point to one level ABOVE the home directory.

So since guest's home is /var/www/uploads/guest, then the ChrootDirectory should point to /var/www/uploads

That's a MAYBE.... another thought occurred to me:

You manually installed the newer openssh, did you remove the old version? Where did the new version get installed? sometimes, if you're not careful, new stuff will get installed into /usr/local/ instead of /usr, meaning the sftp enabled server is reading its config files from /usr/local/etc/ssh/... instead of the expected /etc/ssh/...

Something to check at least.

| improve this answer | |
  • You got it! My new installation of sshd put the binary in the same place as before, but put the config file into /usr/etc instead of /etc/ssh, so I was editing a config file that was no longer used. Although /etc/ssh is the location referenced by all tutorials and by the man page, I couldn't find a config option that would use that location, so I just made my updates to the new config file and now things are working as expected. – arlomedia Jul 2 '12 at 23:15
  • By the way, I did need to set up the directories so that the user's home directory is inside the chroot directory. I had tried that earlier, but since the chroot wasn't enabled at all, it didn't seem to make a difference. I did not, however, need to change the user's shell since that is disabled automatically when chrooting, although I suppose it wouldn't hurt. – arlomedia Jul 2 '12 at 23:16
  • No idea, but certainly pretty easy to test. Glad you got it figured out. (The 'command' you're looking for was probably a --prefix= option on the configure command, I'd have to look it up for sure though) – lornix Jul 2 '12 at 23:34
  • Yes, I had tried several values for --prefix, but couldn't find a value that would put both the binaries and the config file into their original locations. I found one tutorial mentioning that the default location of sshd_config is different in newer versions, but the man pages still refer to /etc/ssh. I suppose I could post this as a separate question, but I'm satisfied with my current setup. – arlomedia Jul 3 '12 at 18:51

I've struggled with the exact same problem, but solved it by setting up the chrooted directory as well as all parent directories with the following permissions

1) Changing owner to root:

sudo chown root [directory]

2) Removing all group write permissions:

sudo chmod 755 [directory]

Sadly I think that means you can't directly jump to a folder not owned by root, but will be happy to hear if anyone can correct me on this!

| improve this answer | |
  • Not only must all parent directories be owned by root, but their group must also be root, for all directories in the path. – Kevin FONTAINE Jul 23 '19 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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