sftp chroot (revisited)

[Tim Nelson]

I am working on setting up some FTP and SFTP chrooted environments.

Using ProFTP for FTP works great with no issues.

I am attempting to use SSH 5.x (HP-UX Secure Shell-A.05.10.008) to do the same with the ChrootDirectory directive for SFTP and have a question.

The chroot functionality in ssh/sftp does in fact work. But it is required that the chrooted directory (e.g. /home/sftptest ) be owned by root with no write perms for the user).
This is great except that I would like to have the chroot'd sftp user to be able to write into their home directory. Because of the root ownership and write restriction requirement they cannot.

The only solution I have seen is to create a subdirectory under their chrooted directory and have the user own that directory. This would also give other multiple users the ability to see all the directories.

I am thinking this should not be this difficult. Chrooted FTP has been around for a long time. Am I missing something ?

Any others have any comments or experiences?

[Steven Schweda · Accepted solution]

> [...] This would also give other multiple
> users the ability to see all the
> directories. [...]

Why? Why can't you set more restrictive
permissions on that user-owned directory?

If you'd like a more detailed answer, it
might help to include more details in your
question. Like, say, actual configuration
file data, "ls -l" listings, and so on.

[Tim Nelson]

Here is an example:

/incoming/client1
/incoming/client2
/incoming/client3

Lock the ftp users of client1, client2, client3 into their respective directories and allow them to write.

One the back side there is one admin login that can get or put files from all the clients directories so the group membership needs to be the same for all in order to allow the admin login to get/put/delete.

I have done this for many years with ProFTP but am working on implementing the same type of solution using SFTP.


Directory would look like this:

drwxrwx-- client1 clients /incoming/client1
drwxrwx-- client2 clients /incoming/client2

sshd_config might look like this.
Match user client1
ChrootDirectory /incoming/%u

Match user client2
ChrootDirectory /incoming/%u


The admin user would be a member of the client group and not restricted. It could then add or remove files from either directory.

I could certainly create more subdirectories under each client but was hoping not to as I would have to change a lot of scripting for each client.

This type of layout works great with ProFTP, locking each user into their respective directory and allowing write access to the chroot.

I was simply hoping to implement the same structure using ssh and limit the changes to the current process/structure.

[Steven Schweda]

> drwxrwx-- client1 clients /incoming/client1
> drwxrwx-- client2 clients /incoming/client2
_ ____^^^

Why let the group do _anything_? Isn't that
the problem?

[Heironimus]

If that HP package is based off a new enough OpenSSH release you (in theory) shouldn't need a whole chroot structure if you use the "internal-sftp" subsystem instead of sftp-server. But I'm not sure what other tradeoffs that may entail, and I'm not sure exactly which OpenSSH release added it. If your man page for sshd_config doesn't mention "internal-sftp" then it's probably too old.

As for what you're missing about chroot FTP, the main thing is probably that SFTP and FTP have nothing in common other than a superficially similar UI and purpose. The actual mechanics are completely different at almost every level. I don't think the OpenSSH developers had untrusted users in mind when they wrote sftp-server.