Feature Request: Chroot Default Shell Escape

[Jochen Bern]

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>