2.4.7.1. Start as unprivileged account and always operate under it¶

This is the default mode on Linux and macOS.

The included unit, init, service, plist files are configured to start SFTPPlus as an unprivileged user.

Also make sure the configuration file reads as follows (account value is empty):

[server]
account =

SFTPPlus will then operate under the same OS account that is used to launch it.

Advantages:

• Operating under the principle of least privilege.

• Even if there are security bugs in SFTPPlus, a successful exploit will not have unprivileged access to OS resources.

• On systemd-based Linux distributions and macOS, the unprivileged user can be assigned non-valid shell and home values such as /bin/false and /var/empty, respectively.

Disadvantages:

• Using ports below 1024 requires OS-specific configuration.

• OS accounts cannot be used for file transfer services.

• On Alpine Linux and Linux distributions using the SysV init file such as Amazon Linux AMI 2018.03, the unprivileged user needs a valid shell and home.

2.4.7.2. Start as root and mostly operate as unprivileged account¶

This is only needed if you require to authenticate OS accounts in SFTPPlus.

To configure SFTPPlus to start as root, but to run under the dedicated application account, you have to edit the default-included unit, init, or service file to use root instead of sftpplus for launching SFTPPlus.

Then make sure the following option is present in the configuration/server.ini configuration file:

[server]
account = sftpplus

Advantages:

• Binding to ports below 1024 works out of the box.

• OS accounts can be used for file transfer services.

• On Alpine Linux and Linux distributions using the SysV init file, for example Amazon Linux AMI 2018.03, the unprivileged user can be assigned non-valid shell and home values such as /bin/false and /var/empty, respectively.

Disadvantages:

• Even though most of the time SFTPPlus will operate under the unprivileged account, for requests to authenticate an OS account SFTPPlus will briefly switch to running as root in order to perform the OS authentication. If there is a security bug in SFTPPlus, and that bug is exploited during the brief amount of time SFTPPlus runs as root, an attacker can theoretically gain privileged access to OS resources.

2.4.7.3. Running SFTPPlus on a Security-Enhanced Linux system¶

Some Linux distributions, such as Red Hat Enterprise Linux and its derivatives, are installed with SELinux set up in "enforcing" mode. That doesn't allow the execution of shell scripts from a user home directory.

To avoid this limitation, when creating the dedicated SFTPPlus OS user manually, use a home directory other than the installation directory of SFTPPlus. For example, assuming that SFTPPlus is being set up at /opt/sftpplus, use these commands to add a dedicated operating system user named sftpplus:

groupadd sftpplus
useradd -g sftpplus -c SFTPPlus -s /bin/sh -d /var/lib/sftpplus -M sftpplus

On top of the above, you'll have to restore the SELinux context for the script SFTPPlus uses to start itself: admin-commands.sh.

For example, assuming the SFTPPlus is being set up at /opt/sftpplus:

restorecon -v /opt/sftpplus/bin/admin-commands.sh

2.4.7.4. Running multiple concurrent instances on the same system¶

You can run multiple independent SFTPPlus instances on the same machine or VM to achieve one of the following requirements:

• have separate testing and production systems

• better CPU usage and high availability on multi CPU / multi disk systems

• create a pre-production system which is hosted by the same VM as the production to allow easy rollback to older version

On systemd (modern Linux) and OpenRC init systems, this can be achieved by creating multiple service files with different names and setting specific configuration files per SFTPPlus instance.

When using the supplied bin/install.sh script to set up these instances, it's as simple as providing a custom name for the SFTPPlus service of the instance to be set up when installing from multiple locations. For example:

/opt/sftpplus-production/install.sh --service-name=sftpplus-prod
/opt/sftpplus-testing/install.sh --service-name=sftpplus-test

This takes care of all the needed system configuration. You can still use the provided shell scripts to safely update or uninstall these instances individually. Just make sure the concurrent instances are configured to use different ports for their services. For example, considering the default-enabled FTP / SSH / HTTPS / Web Manager services, you might use the 21/22/443/8443 ports for the production instance, while using the default 10021/10022/10443/10020 ports for the testing instance. Only install a new SFTPPlus instance this way after making sure the default SFTPPlus ports are free, to have both fully working side by side.

If you prefer to set up multiple SFTPPlus instances manually, each instance must be configured with specific paths for log and cache files. For example, when using a production instance and a testing one, log/server-production.log and log/server-testing.log for the log handler's file paths, and configuration/cache-production.db3 and configuration/cache-testing.db3 for the embedded database resource paths.

In addition, different instances must use different ports and/or IPs. For example, 10022 for the first instance's SFTP port and 20022 for the second one, if using the same IP.

For SysV-based systems, we provide a simplified init script for running concurrent instances: bin/sftpplus-mft.sysv.instances.sh. Create copies as needed in your /etc/init.d/ sub-directory, then edit the $INSTANCE_ID variable for each instance. The init script assumes each instance is configured through a file named configuration/server-INSTANCE_ID.ini, where INSTANCE_ID should match the value set in the init script.

When running different versions of SFTPPlus concurrently on the same machine, each instance has a dedicated root directory, therefore the INSTALL_ROOT variable from the service/init files must be updated accordingly.