Feature Request: Chroot Default Shell Escape

[Konstantinos Pipinis]

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
the sftp.


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
tool.


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>
           AllowDefaultShellEscapeChroot  yes