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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210121/5a2e2113/attachment.p7s>