openssh unix dev - Jan 2021 - Feature Request: Chroot Default Shell Escape

Dear developers,

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.

Thank you for your time and consideration. And of course for the amazing
project that is openssh.

Best regards,
Pipinis Konstantinos

PS: This is something I have already implemented and could implement for
the mainstream OpenSSH source.

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>