There's absolutely no useful documentation on "User - System: Copy files to home directory (chrooted scp)"

rcfa · Jan 27, 2024, 6:36 PM

In the manual section here:

https://docs.netgate.com/pfsense/en/latest/usermanager/privileges.html#usermanager-privileges

there is absolutely zero documentation on the privilege

User - System: Copy files to home directory (chrooted scp)

When looking at the Web UI "documentation" it only says:

Warning: Manual chroot setup required, see /usr/local/etc/rc.d/scponlyc.

If I look at the file, I get these voluminous instructions:

# Add the following lines to /etc/rc.conf to enable scponly:
# scponlyc_enable (bool):		Set to "NO" by default.
#					Set it to "YES" to enable scponly
# scponlyc_shells (str):		Set to "/etc/shells" by default.
# scponlyc_passwd (str):		Set to "/etc/passwd" by default.

Funnily enough, if I look at /etc/rc.conf I get this:

# THIS FILE DOES NOTHING, DO NOT MAKE CONFIG CHANGES HERE

Ah, great!

So then I searched the forums, and all I could find were these two threads, both with ZERO answers:

https://forum.netgate.com/topic/123939/privilege-user-system-copy-files-to-home-directory-chrooted-scp

https://forum.netgate.com/topic/181276/add-user-and-enable-chroot-ssh-scp-access

I'm trying to do something different than what's the goal of the people who started the above threads, but the lack of documentation is the same:

https://forum.netgate.com/topic/185797/webroot-ftp-with-local-chrooted-user

So, anyone PRETTY PLEASE!!!

rcfa · Jan 27, 2024, 7:58 PM

@rcfa So, I suspect that

# Add the following lines to /etc/rc.conf to enable scponly:

is the first thing that's wrong.

/etc/rc,conf seems to be an unused stub, while in reality /etc/defaults/rc.conf is being used, except for the latter starts with this warning:

# This is rc.conf - a file full of useful variables that you can set
# to change the default startup behavior of your system.  You should
# not edit this file!  Put any overrides into one of the ${rc_conf_files}
# instead and you will be able to update these defaults later without
# spamming your local configuration information.
#
# The ${rc_conf_files} files should only contain values which override
# values set in this file.  This eases the upgrade path when defaults
# are changed and new features are added.

which leads me to believe that what one really should do is to CREATE a new file in /usr/local/etc/rc.conf.d/ such as /usr/local/etc/rc.conf.d/scponly and add the lines

# scponlyc_enable (bool):		Set to "NO" by default.
#					Set it to "YES" to enable scponly
# scponlyc_shells (str):		Set to "/etc/shells" by default.
# scponlyc_passwd (str):		Set to "/etc/passwd" by default.
scponlyc_enable="YES"

to it. Does that sound right?

Also, since /etc/shells doesn't list /usr/local/bin/scponly it would seem that it would have to be added there, otherwise it wouldn't be a valid login shell, right? (Which is another piece missing from the docs, if true!)
That would mean, /etc/shells would look like this:

#
# List of acceptable shells for chpass(1).
# ftpd(8) will not allow users to connect who are not using
# one of these shells.

/bin/sh
/bin/csh
/bin/tcsh
/usr/local/libexec/git-core/git-shell
/usr/local/bin/bash
/usr/local/bin/rbash
/usr/local/bin/scponly

That's at least my current working hypothesis...

rcfa · Jan 27, 2024, 9:01 PM

@rcfa So, the rabit hole gets deeper. I get my testuser to be able to log in, just to be kicked out again...
...first reason: the /home/testuser folder wasn't owned by root, which for a chrooted environment seems to be a must. OK, fixed that.

...second reason: I now would have to set up a complete chroot environment, which is a PITA, and is even more of a PITA to back up and restore in the future....
...or I could simply add this to /etc/ssh/sshd_config

Match User user
    ChrootDirectory /home/testuser
    ForceCommand internal-sftp

but alas, I find this in /etc/ssh/sshd_config

# This file is automatically generated at startup

So this means, I can't put anything into that file without it getting overwritten instantly with each reboot, so that's not a solution. So it seems that the UI is missing some way to add user defined options to /etc/ssh/sshd_config

Anyone got ideas?

rcfa · Jan 27, 2024, 10:38 PM

@rcfa So, looking at /etc/sshd I find this section:

/* Apply package SSHDCond settings if config file exists */
if (file_exists("/etc/sshd_extra")) {
    $fdExtra = fopen("/etc/sshd_extra", 'r');
    $szExtra = fread($fdExtra, 1048576); // Read up to 1MB from extra file
    $sshconf .= $szExtra;
    fclose($fdExtra);
}

which, if I interpret it correctly, means that the contents of a file /etc/sshd_extra is appended to /etc/ssh/sshd_config , if it exists, a thing easy enough to do, BUT...

without UI this means very likely that what ever one puts into that file will not be backed up with the system configuration
what's package " SSHDCond "? It doesn't improve matters, if I put things in /etc/sshd_extra but then some (what?) package potentially stomps on it...

rcfa · Jan 27, 2024, 10:51 PM

@rcfa Another issue: scponly requires that the home directory be owned by root, but of course, despite setting the user privilege to chrooted scp, it's not owned by root, but by the user. So no matter what, it seemingly has to manually changed to be owned by root...

rcfa · Jan 29, 2024, 4:27 PM

@rcfa So, I got things working, but as far as I'm concerned, it's a hack.
It's not a hack from a BSD perspective, but from a pfSense perspective, because I'm not sure what exactly I'm overriding or what exactly might override me, when it's least expected; AND most importantly: I'm fairly sure none of these changes will get backed up.

So here my steps:

create a new user in the user manager, for my purposes I'll call the user acme as I started this whole exercise for the FTP webroot ACME certificate challenge...
ensure the user isn't part of any of the special privileged groups (shouldn't be the case, but check anyway)
Under "Effective Privileges" add ONLY User - System: Copy files to home directory (chrooted scp)
chown root /home/acme
*rm /home/acme/. **
append the line /usr/local/bin/scponly to the bottom of /etc/shells
create the file /etc/sshd_extra with the contents

Match User acme
    ChrootDirectory %h
    ForceCommand internal-sftp

create the file /usr/local/etc/rc.conf.d/scponly with the contents

# scponlyc_enable (bool):		Set to "NO" by default.
#					Set it to "YES" to enable scponly
# scponlyc_shells (str):		Set to "/etc/shells" by default.
# scponlyc_passwd (str):		Set to "/etc/passwd" by default.
scponlyc_enable="YES"

fix the permissions with chmod a+x /usr/local/etc/rc.conf.d/scponly
reboot the system
sftp acme@host.domain.tld
Enjoy! (Until the initially mentioned concerns eat at your soul...)
just kidding! pfSense, well meaningly, but completely sabotaging this approach, makes sure all user home folders have "the correct ownership" upon reboot, or so it seems. You reboot the machine, and even though you set /home/acme to be owned by root before, it's back to being owned by acme!
So now, add a new crontab entry with time @reboot run by root and the following command:
/bin/sleep 300 && /bin/test -d /home/acme && /bin/test ! -O /home/acme && /usr/sbin/chown root /home/acme
This runs once after each reboot, with a 5 minute (300 seconds) delay, and checks if the home folder exists, isn't owned by the user running the current process (root), and if so, sets the ownership to root; this should prevent excessive writing, i.e. just periodically resetting ownership to root.
Now you can enjoy! Can you?

PS: If you don't like to interfere with the system, and let it do its user management thing, you can of course also do something else:

create a new user in the user manager, for my purposes I'll call the user acme as I started this whole exercise for the FTP webroot ACME certificate challenge...
ensure the user isn't part of any of the special privileged groups (shouldn't be the case, but check anyway)
Under "Effective Privileges" add ONLY User - System: Copy files to home directory (chrooted scp)
append the line /usr/local/bin/scponly to the bottom of /etc/shells
mkdir /home/acme/sftproot
chown root /home/acme/sftproot
create the file /etc/sshd_extra with the contents

Match User acme
    ChrootDirectory %h/sftproot
    ForceCommand internal-sftp

create the file /usr/local/etc/rc.conf.d/scponly with the contents

# scponlyc_enable (bool):		Set to "NO" by default.
#					Set it to "YES" to enable scponly
# scponlyc_shells (str):		Set to "/etc/shells" by default.
# scponlyc_passwd (str):		Set to "/etc/passwd" by default.
scponlyc_enable="YES"

fix the permissions with chmod a+x /usr/local/etc/rc.conf.d/scponly
reboot the system
sftp acme@host.domain.tld
Enjoy! (Until the initially mentioned concerns eat at your soul...)

In either case you can read from the respective sftp root directories, to write anything, you'll need to create subfolders, which are then owned by acme user, and you can write/put into these directories, but not into the sftp root directory, regardless of which setup version you picked.

rcfa · Jan 28, 2024, 5:22 PM

I submitted a few related bug reports and enhancement requests, in case anyone is going to track this or suggest solutions:

https://redmine.pfsense.org/issues/15199
https://redmine.pfsense.org/issues/15200
https://redmine.pfsense.org/issues/15203
https://redmine.pfsense.org/issues/15209