On a previous deploy, ops had configured something like

Subsystem sftp internal-sftp

Match Group filedrop
    ChrootDirectory %h
    AllowTCPForwarding no
    X11Forwarding no

That build of ssh seems to have a bunch of checks knocked out and
does not notice when you mess up the permissions on the .ssh folder.

On trying to test a replacement on a test server I found out this
configuration doesn't work. The test user is Uaaaa, has a home directory
of /u/Uaaaa, and /u is mounted noexec.

Documentation I found says this should work: https://unix.stackexchange.com/a/396684

Adding ForceCommand internal-sftp doesn't help. That's not the problem.

I'm pretty sure I could fix this by adding a statvfs() call to check
if the directory is noexec or not. Getting such a change approved is
harder than making it.

I've since learned this bug is upstream; and have most of a fix.
Basically I'm bogged down in autoconf; which makes it unsuitable for
upstream but I could provide a debian specific patch without autoconf.

I don't think the openssh team likes gmail much; the mailing list for
reporting anything upstream doesn't want to let me join or send
anything.

I've thought about it, and constructing a chroot directory per user is
a rather big ask on server support; it really does seem like allowing
ChrootDirectory %h to work with a writable home directory is better
than any alternative. It's actually less effort to patch locally but a
local rebuild in the middle of the night is a pill.

I'd probably want this sort of patch to go upstream first.

You can file upstream bugs with attached patches on
bugzilla.mindrot.org, which IME is usually more reliable anyway.