Feature Request: Chroot Default Shell Escape
k.s.pipinis at gmail.com
Thu Jan 21 20:45:33 AEDT 2021
If you have a shell that you consider safe for those users to use (*not*
a trivial requirement!), make it their login shell and stop
ForceCommand'ing them into an SFTP server; both shell and SFTP will be
available from that point on.
ChrootDirectory should(*) work regardless of what kind of session ensues
(as long as your shell is *able* to run in the chroot, of course).
If you do not force the SFTP subsystem, the shell would be available
as long as the user does have a copy of the relevant to the shell
files inside his chroot jail. When this is applied to many users (than
in our case were dynamically created), there is a constraint in the
case of limited storage space (like most IOT devices). The other
option is to mount the folders containing the relevant to the shell
files, but this also is a security risk as you expose much more than
intended and the mounted folders are now (possibly) modifiable through
Having SFTP sessions chroot()ed but *not* the shell ... does sound like
one security setting likely defeating the other, to be honest ...
That may initially sound true, because in most cases the shell is the
bash or something similar and has the capabilities to modify the file
system and can move files in and out of the chroot. Thus having chroot
for the sftp alone does defeat the purpose. BUT, if the shell does not
provide those capabilities, the shell and the sftp are two seperate
systems with their own security features, and ssh acts as a tunneling
FWIW, if you still want to suggest a new feature *for the SFTP server*,
please specify which one you're using in your Subsystem config.
What we currently use looks like this:
Subsystem sftp internal-sftp
Match Group <Group name>
ChrootDirectory <path to directory>
More information about the openssh-unix-dev