[EDIT] Sim, acredito que seja possível, mas também acredito que não com o openssh:
Aqui está como eu chroot sftp usando openssh:
Eu coloco os usuários do sftp em um grupo especial sftponly que é identificado no arquivo sshd_config . Eu me certifico de que os usuários do sftp não possuam shell (para que eles não possam efetuar login com ssh) e usem a variável de ambiente .%h para forçá-los a um subdiretório sftp chroot com o nome do diretório home usando a diretiva ChrootDirectory . Outras variáveis de ambiente interpretadas por sshd_config estão documentadas no página man do sshd_conf assim:
The pathname may contain the following tokens that are expanded at runtime once the connecting user has been authenticated: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated, and %u is replaced by the username of that user.
Aqui está uma cópia das minhas anotações para conseguir isso no OpenBSD, se você usar um sistema diferente, a variável de ambiente .%h pode diferir:
# 1. Create the sftp jail directories
# These directory permissions work with this /etc/ssh/sshd_config:
# drwxr-xr-x 4 root wheel 512 May 14 16:20 /home/sftproot
# drwxr-xr-x 3 root wheel 512 May 14 16:21 /home/sftproot/home
# drwxr-xr-x 3 root wheel 512 May 14 16:37 /home/sftproot/home/User01
# drwxr-xr-x 3 User01 sftponly 512 May 14 16:39 /home/sftproot/home/User01/upload
# drwxr-xr-x 3 root wheel 512 May 14 16:37 /home/sftproot/home/User02
# drwxr-xr-x 3 User02 sftponly 512 May 14 16:39 /home/sftproot/home/User02/upload
# 2. Make sure /etc/ssh/sshd_config jails /home/sftproot/.%h
# 3. Create a group whose members will only be allowed sftp access
# groupadd sftponly
# 4. Create User01 + User02 whom will only get sftp access
# useradd -s /sbin/nologin -m -G sftponly User01
# useradd -s /sbin/nologin -m -G sftponly User02
# 5. In /etc/ssh/sshd_config enable use of chroot(internal-sftp) then force chroot dirs per user:
# override default of no subsystems
# Subsystem sftp /usr/libexec/sftp-server
# Subsystem sftp internal-sftp
# Rules for sftponly members
# Match group sftponly
# ChrootDirectory /home/sftproot/.%h
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand internal-sftp
# [Comment] Make sure /etc/ssh/sshd_config jails /home/sftproot/.%h
# Which will translate .%h to /home/$username
# [Comment] The sftp users will not be able to log in outside of sftp (as they have no shell).
# As they sftp in they will land in the /home/sftproot/home/Userxx directory which
# will be named "./" and where they have no write access.
# However the directory ./upload is read/writable.
[EDIT parte 2] No entanto, o sshd_conf man page também especifica que:
ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. 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. After the chroot, sshd(8) changes the working directory to the user's home directory.
Assim, o caminho do diretório chroot, incluindo a parte especificada pela expansão da variável, é esperado e testado pelo sshd para ser possuído e gravável exclusivamente pelo root. Portanto, um usuário de um serviço chrooted do openssh sftp precisa de subdiretórios graváveis para poder gravar no diretório inicial.
Acredito que isso não seja um requisito para todos os servidores ssh. Também usamos Tectia , onde observo que os usuários podem gravar em seus respectivos diretórios raiz. No entanto, nós o executamos apenas onde o Windows é um requisito, portanto, lamentavelmente não posso testar prontamente a configuração * nix correspondente. A página de suporte do chrooting do Tectia sftp não Especifique explicitamente que a página inicial do usuário precisa ser de propriedade do root em um ambiente Unix. Eu diria, portanto, que com o Tectia isso não é um requisito, mas que a propriedade de um rootdir de usuário root pode ser a do usuário real.