Help with sftp-only chroot configuration.

[mpua]

Hello,

I'm trying to create a new chrooted sftp-only environment to replace and old plain jailed  FTP structure.

The idea is to put together a set of chrooted sftp-only users which should in the home directories under /sftp, each one of them chrooted in its home directory.

I want the sftp users to be logged directly into their homes under /sftp/home, so I've put the following directive in the sshd_config file:  ChrootDirectory %h.

When I chown the home user directories (for instance, /sftp/home/user) to the respective user, I get an error like this when try ing to log in with a SFTP client:

 fatal: bad ownership or modes for chroot directory "/sftp/home/user"

I've reading up on this issue and it seems I /sftp/home/user must be owned by root... but that doesn't work for me since I want the users to be able to write in their home directory (wihout having to chmod the home dirs to 777....).

Is there any way of solving this?

P.S. This thread has been moved from HP-UX > General to HP-UX > networking. - Hp Forum moderator

[Matti_Kurkela · Accepted solution]

I did something similar on RHEL 6 recently.

The problem might be two-fold:

• modern sshd has a hard requirement that the ChrootDirectory is owned by root and not writeable by anyone else.
• sshd reads the home directory pathname from the real /etc/passwd, then performs the chroot, and then tries to apply the real home directory pathname within the chroot (if your sshd is newer than RHEL 6's, there might have been a patch to improve this behavior). If a directory matching the home directory pathname does not exist within the chroot, it falls back to / within the chroot.

You might be able to work around the ChrootDirectory ownership requirement by using ACLs, since sshd might not be able to check that. But I've understood there is a security-related reason why the check is implemented, and this workaround might become useless if/when sshd is updated to check for ACLs too.

Relying on the "fallback to /" behavior might also cause the user to see scary "home directory not found" error messages, or pollute the logs with them.

I considered patching sshd to try removing the pathname elements matching the ChrootDirectory setting from the beginning of the home directory path, but in my case, using a non-default sshd was not an option.

So I did it like this:

I specified the home directory path for chrooted users as /sftp/<username>_chroot/<username>, then set the ChrootDirectory parameter to "/sftp/%u_chroot".

Then I made a couple of symbolic links, exactly like this:

cd /sftp/<username>_chroot

ln -s . /sftp/<username>_chroot/sftp

ln -s . /sftp/<username>_chroot/<username>_chroot

As a result, when the home directory pathname is read from /etc/passwd, the result is /sftp/<username>_chroot/<username> and all is well. When a SFTP session logs in and gets chrooted to /sftp/<username>_chroot,

the same pathname will match the symbolic links:

• /sftp will match the symlink at /sftp/<username>_chroot/sftp, which points to .
• then, <username>_chroot will match the symlink at </sftp/<username>_chroot/<username>_chroot, which points to . again.

So, within the chrooted environment, the pathname /sftp/<username>_chroot/<username> maps to /././<username>, which is obviously the same as /<username>. Now, that can be a valid user home directory within the chroot, and can be owned by the user. Obviously, if you want to use SSH keys for authentication, the standard rules apply: the home directory and the .ssh sub-directory must not be group or world writeable. Sub-directories of the home directory can be set however you want.

With this set-up, you can also easily set up /sftp/<username>_chroot/etc with a minimal /etc/passwd and /etc/group, to allow the chrooted SFTP client to see human-readable user/group names instead of UID/GID numbers. (Those user/group names don't even have to match the true user/group names.)

If you need copies of any other system files, these can be neatly placed to other corresponding sub-directories ofthe /sftp/<username>_chroot level and made read-only, so the chrooted user won't be able to screw up his environment.

For example, if your users care about file timestamps in the chrooted environment and your timezone uses DST, you might need to provide a copy of /usr/lib/tztab as /sftp/<username>_chroot/usr/lib/tztab, and make sure that the SFTP session gets a valid TZ environment variable.

[mpua]

Many thanks Matti, sorry I couldnt answer before. I'll try to setup this configuration you're suggesting. Let's see how it goes!