On 20.01.21 12:10, Konstantinos Pipinis wrote: > The SSH daemon allows sftp connections (through internal-sftp) to a chroot > directory for specific users or groups. This prevents them from having > access with a regular ssh connection to their default terminal (as it > should prevent). > Yet, there are cases (as I had the need to implement) where a custom shell > (eg: used for system configurations) is provided for some users while > simultaneously the users had access only to their designated folder using > the chroot-sftp functionality (in order to download or upload configuration > files and logs). > > I would suggest the option for the default shell (as set in passwd) to > escape chroot and execute as normal. 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). Other options that you may have specified in the ForceCommand should(*) work the same in the Subsystem statement. Having SFTP sessions chroot()ed but *not* the shell ... does sound like one security setting likely defeating the other, to be honest ... 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. (*) Disclaimer: Per the manpages, never tried that myself. Regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
