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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev