1

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?

Improve this question

2 Answers 2

Reset to default
1

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
4
  • 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
    Commented Jul 2, 2012 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
    Commented Jul 2, 2012 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
    Commented Jul 2, 2012 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
    Commented Jul 3, 2012 at 18:51
0

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
1
  • 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
    Commented Jul 23, 2019 at 15:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .