Have a config that looks like this
AllowUsers sftpu
Match Group sftpg
ChrootDirectory /home/sftp
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no
the passwd
entry (group 7700 is named sftpg
)
sftpu:x:7700:7700::/home/sftp/allu:/bin/false
and the allu
dir
drwxrwxr-x 4 guacam sftpg 4096 Sep 16 2019 /home/sftp/allu/
That almost works. The chroot works, but unlike what the man says
After the chroot, sshd(8) changes the working directory to the user's home directory
the working dir of the user after login is /home/sftp
, not /home/sftp/allu
, and my guess is that because /home/sftp/allu
belongs to guacam
and not sftpu
(while the sftpg
group has rwx
access in allu
and could write. That's because several users should share that same allu
dir).
Unless the config above is flawed, is there a command in the sshd subsystem to either
- force the chdir (after chroot) to go to the user's home
- relax a bit the access rules
- ...
while keeping the same directory tree and accesses?
sshd can't change the working directory to the user's home directory because it doesn't exist. It therefore leaves the working directory set to
/
.You assigned this user the home directory
/home/sftp/allu
. But then you chroot the user to/home/sftp
. That means that relative to the chroot, that directory is at/allu
! Not/home/sftp/allu
.You need to know that chroot causes the root directory that the logged in user can access will be changed to some lower point in the filesystem, and that all paths are relative to that. So if a user must access
/home/sftp/allu
inside a chroot directory/home/sftp
, then outside in the real filesystem, the directory would be/home/sftp/home/sftp/allu
.