Mailing List Archive

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

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