SFTP user chroot shell path update & ls addition

[phillxnet]

During #2858's development, it was noted that we have the following shell setup enforced for SFTP users:

rockstor-core/src/rockstor/system/ssh.py

Line 253 in ce44243

run_command([USERMOD, "-s", "/bin/bash", user], log=True)

I.e. we modify the SFTP user's shell to /bin/bash which is likely now inconsistent with the new chroot environment setup by way of SFTP configuration.

---

Reproducer of consequent behaviour to follow.

[phillxnet]

Post having enabled sftp we have the following config for the specific user (owner of the share we sftp export):
via:

cat /etc/ssh/sshd_config

###BEGIN: Rockstor SFTP CONFIG. DO NOT EDIT BELOW THIS LINE###
Subsystem       sftp    internal-sftp
AllowUsers root sftp-user
Match User sftp-user
        ForceCommand internal-sftp
        ChrootDirectory /mnt3/sftp-user
        X11Forwarding no
        AllowTcpForwarding no

With a necessary minor edit (remarking out) above this re the sftp subsystem line:

#Subsystem sftp /usr/lib/ssh/sftp-server

[phillxnet]

Once we setup a proposed sftp-user, and a SFTP share owned by them, i.e. sftp-share and enable the export of this share we have the setup used during the final testing of #2858 (#2858 (comment)):

As per documented setup:
"Secure File Transport Protocol (SFTP)"
https://rockstor.com/docs/interface/storage/file_sharing/sftp.html

1. create sftp-user
2. create sftp-share
3. Edit sftp-share Access control to owner=sftp-user
4. Add SFTP Share sftp-share

If we then attempt to ssh in as this user:

ssh [email protected]
Password: 

The result we receive is, as per our "ForceCommand internal-sftp" configuration":

This service allows sftp connections only.
Connection to rleap15-6.lan closed.

See PR: "Configure SFTP server at buildtime and update customization settings. Fixes #2168" #2173 for the origin of this config development:

In addition, this PR also takes the opportunity to add per-user customization settings to be in accordance with the settings recommended on hte openSUSE wiki:
https://en.opensuse.org/SDB:SFTP_server_with_Chroot#Match_rule_block

[phillxnet]

So given the last comment, our now inconsistent bash path, given the changes to our chroot introduced in #2858, has no current artifacts as we "ForceCommand" the internal-sftp as the user's 'shell'. However we may want to accommodate custom behaviour in the future that utilises our chroot setup. Doing a quick investigation of this now re:

rockstor-core/src/rockstor/system/ssh.py

Lines 143 to 154 in 701b44c

	# Set options for each user according to openSUSE's defaults:
	# https://en.opensuse.org/SDB:SFTP_server_with_Chroot#Match_rule_block
	# TODO: implement webUI element to re-enable rsync over ssh by omitting
	# the `ForceCommand internal-sftp` line below.
	for user in input_map:
	tfo.write("Match User {}\n".format(user))
	tfo.write("\tForceCommand internal-sftp\n")
	tfo.write("\tChrootDirectory {}\n".format(input_map[user]))
	tfo.write("\tX11Forwarding no\n")
	tfo.write("\tAllowTcpForwarding no\n")
	move(npath, SSHD_CONFIG[distro_id].sftp)

[phillxnet]

By way of testing a future modification re no or custom ForceCommand, if we remove the ForceCommand line, and stop/start all rockstor* services; then wipe/re-enable the same sftp-share export we end-up with the following config:

###BEGIN: Rockstor SFTP CONFIG. DO NOT EDIT BELOW THIS LINE###
Subsystem       sftp    internal-sftp
AllowUsers root sftp-user
Match User sftp-user
        ChrootDirectory /mnt3/sftp-user
        X11Forwarding no
        AllowTcpForwarding no

We end-up running into the issue anticipated bash path fail within our chroot:

ssh [email protected]
Password: 
Have a lot of fun...
Last login: -----------------------------
/bin/bash: No such file or directory
Connection to rleap15-6.lan closed.

[phillxnet]

If we correct the sftp-user shell path, stop/start all rockstor* services and exercise our proposed custom sftp/ssh config with the ForceCommand line removed from the referenced code above (restoring a chroot bash shell) we have a successful ssh login for the same sftp-user:

ssh [email protected]
Password: 
Have a lot of fun...
Last login: Mon Jul  8 18:26:30 2024 from 192.168.2.172
-bash-4.4$

This is a highly constrained shell, as intended, as we have only bash and rsync binaries (plus lib dependencies) accessible: but that is outside the scope of this issue. I.e.:

-bash-4.4$ ls
-bash: ls: command not found
-bash-4.4$

but we have our intended rsync binary available:

-bash-4.4$ rsync --version
rsync  version 3.2.7  protocol version 31
...

We also see in our Web-UI the sftp-user's Shell entry as follows:

Username	UID	Group	GID	Shell
sftp-user	1006	users	100	/usr/bin/bash

[phillxnet]

By way of providing at least ls if we add this to our PROGS_IN_CHROOT , along with our user Shell path correction, we can see at least our chroot's \ thus:

ssh [email protected]
Password: 
Have a lot of fun...
Last login: ...
-bash-4.4$ ls -la
total 0
drwxr-xr-x 1    0 0  42 Jul  8 17:48 .
drwxr-xr-x 1    0 0  42 Jul  8 17:48 ..
drwxr-xr-x 1    0 0   0 Jun 28 17:01 lib
drwxr-xr-x 1    0 0 182 Jun 28 10:23 lib64
drwxr-xr-x 1 1006 0   0 Jul  8 16:05 sftp-share
drwxr-xr-x 1    0 0  16 Jun 28 10:23 usr

Assuming the proposed user intervention of removing our overarching constraint of the "ForcedCommand" limitation for all SFTP users.

[phillxnet]

Closing as:
Fixed by #2865