What explains this sftp login success/failure behaviour in conjunction with different ftp directory chmod settings?

Question

If I start off with -

sudo groupadd test_group
sudo useradd -g test_group -s /sbin/nologin test_user
sudo passwd test_user
    ...(some password)...
sudo mkdir -p /testdir/dev

And I also have '/etc/ssh/sshd_config' as follows -

Include /etc/ssh/sshd_config.d/*.conf
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp internal-sftp
Match User test_user
        ChrootDirectory /testdir
        PermitTunnel no
        ForceCommand internal-sftp -d /dev
        X11Forwarding no
        AllowTcpForwarding no

also without any 'iptables' rules in place, then I can successfully SFTP connect from another machine (in this case, it's a windows pc, using filezilla), specifying the 'test_user' user name and the password, and it shows and restricts me to the contents of the /testdir/dev directory only.

However, I notice the SFTP session only lists the directory contents; it doesn't have permission to actually send/write files. I.e. I have -

drwxr-xr-x  root root ... /testdir
drwxr-xr-x  root root ... /testdir/dev

Fair enough. So now I want to tighten up ownership and permissions so that my 'test_user' can read & write under the '/testdir', and any 'test_group' users can read, and no other have any access. I then do -

sudo chown -R test_user:test_group /testdir
sudo chmod -R 640 /testdir

Now, my previously successful SFTP connection now fails, saying, "Error: Could not connect to the server".

Not sure why but what about the much more liberal, free-for all permissions -

sudo chown -R test_user:test_group /testdir
sudo chmod -R 777 /testdir

Same sftp failure for my 'test_user' connection.

A little puzzled, I put ownership back to the original case but now with broader access permissions -

sudo chown -R root:root /testdir
sudo chmod -R 775 /testdir

This still fails to connect, remembering that previously with user:rwx, group:r-x, other:r-x root root succeeded and I now have user:rwx, group:rwx, other:r-x root root, which is broader but now SFTP fails.

Then, just to confirm, I tighten up access permissions with -

sudo chown -R root:root /testdir
sudo chmod -R 755 /testdir

and my sftp/filezilla 'test_user' + pw connection succeeds again, shows the /testdir/dev directory's contents, although still without allowing write permissions.

I'm obviously misunderstanding the ownership and access permissions and probably the mechanics of what the sftp service ends up trying to do here. Can someone explain -

1. The 'chmod -R 640 /testdir' and owner 'test_user:test_group' (rw- r-- --- test_user test_group) case seems like what I should need ('test_user' can read and write and other members of 'test_group' can read) - right? - but why does this result in the sftp connection failure?
2. If the 'd rwx r-x r-x root root' case enable a successful sftp connection, connecting with user 'test_user', then why does only broadening permissions to 'd rwx rwx r-x root root' (775) then cause the sftp connection to fail?
3. What is the correct/best way to allow my 'test_user' read/write access to these '/testdir/...' directories through a SFTP connection, with no access to other (non-root) users?
4. Is there a more detailed description of the sequence of steps and processes (perhaps running under different users) throughout this SFTP connection/authentication phase on the sftp server that can give a clearer, more intuitive picture of what's going on here?

Answer 1

The documentation for the ChrootDirectory sshd option says in part:

At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group.

In other words, your /testdir directory must be owned by root without write permission for group or other. If those conditions aren't met, I believe sshd will drop the session.

These restrictions only apply to the chroot directory and its parent directories. You can create files and directories inside /testdir with whatever ownership and permissions you like.