10

I have a setup with sftp only users:

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

I get the following message in my secure.log:

fatal: bad ownership or modes for chroot directory

With the match keyword there comes some security stuff with it... the directories need to be owned by root, and the directories need to be chmod 755 (drwxr-xr-x). So it makes it impossible for a user to have write permissions to the folders, if it is only writable to the user root and set to ben non-writable for groups due to ssh's security.

Someone know about a good work around?

1
  • Do the chrooted users own their ChrootDirectory ? Can they access it ? Jul 31, 2014 at 15:05

6 Answers 6

7

We've found a workaround recently that goes like this:

/etc/ssh/sshd_config:

...

Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /home
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

directory permissions:

root@server:~ # chown root:root /home
root@server:~ # chmod 111 /home
root@server:~ # chmod 700 /home/*

Now /home satisfies the requirements for ChrootDirectory and can't be listed by restricted users, but sftponly users will not be able to log in if their home directories are set up as usual (/home/$LOGNAME): under the chrooted environment their home directories aren't inside /home but directly under root (/).

workaround 1

Set restricted users' homes to how they appear under chroot:

root@server:~ # usermod -d /username username

caveate 1

If any of the unrestricted users or some administration script uses bash's tilde expansion like ~username it will expand to /username now, which isn't what is meant.

Also the admin that creates sftponly users has to remember to use non-default home. Solveable with a script. Which the admin has to remember to use.

workaround 2

This is an alternative to the previous one that we ended up using:

root@server:~ # ln -s . /home/home

That is create a symlink inside /home to its own dirname. Now under chroot /home/username points to the same directory as without chroot. For restricted user logged in with sftp it would appear as /username. This directory is writable to its owner (restricted user). Restricted user can't list its parent or home directories of any of the siblings by name.

The only thing special about an sftponly user is its participation in the sftponly group. We found it easier to deal with than the workaround 1.

caveates 2

  1. You can't have user named 'home' with a home directory /home/home
  2. You have to be careful with scripts that traverse /home hierarchy and follow symlinks.
1
  • Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?
    – Blatant
    Feb 8, 2017 at 18:48
4

You need to create a structure inside the user's home directory, like in and out dirs. Those dirs should be owned by the user and there he will be able to put and get files.

2

I have same settings on our server. We use same config of SSHD. Users' home directories are owned by root and within them there are folders documents and public_html owned by respective users. Users then login using SFTP and write into those folders (not directly into home). As SSH is not allowed for them, it perfectly works. You can adjust which directories will be created for new users in /etc/skel/ (at least in openSUSE, I'm not so familiar with other distros).

Another possibility would be ACL (openSUSE documentation) - it can add write permission for respective user for his home directory.

1
  • 1
    For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe Feb 18, 2018 at 3:19
0

You should create the following directory structure:

/home/user

/home/user/home/user <- the real dir that the user will have access

Optionally:

/home/user/.ssh/authorized_keys <- if you wanna to authenticate with a public key

0

In reference to the 'directory permissions' section in the answer from @artm (which I just tested) .. I found:

root@server:~ # chmod 111 /home <- Does not work

It doesn't allow the sftp connection to work on ubuntu with execute only permissions on everything i.e. 111.

I found that:

root@server:~ # chmod 555 /home

Works with connection to sftp with the Read and Execute permissions i.e. 555. Not sure if debian vs other flavors are different, but that's what works on my ubuntu installs.

0

When you create a user, you have to set the ownership using chown to every dir for every user.

For example:

sudo chown usertest:groupsftp /home/rootsftp/usertest

You must log in to answer this question.

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