SFTPPlus will associate all operating system accounts not defined in the configuration file with the group named DEFAULT_GROUP.
To disable these accounts you will have to disable the DEFAULT_GROUP group.
Here is an example of a disabled DEFAULT_GROUP:
[DEFAULT_GROUP]
enabled = No
type = group
To enable only a subset of the operating system accounts, you will first need to disable the default group associated with OS accounts, DEFAULT_GROUP, and then create a new group dedicated to the specific OS accounts that you want to enable on the server.
Here is an example in which DEFAULT_GROUP is disabled, a new group is created with the name os_file_transfer, and the specific OS account mike is associated with the new group:
[DEFAULT_GROUP]
enabled = No
type = group
[os_file_transfer]
enabled = Yes
type = group
home_folder_path = ${OS_HOME}
ssh_authorized_keys_path = Disabled
allow_certificate_authentication = No
[mike]
enabled = yes
type = os
group = os_file_transfer
home_folder_path = Inherit
Note
No password is defined for the mike account. Being of type os, the account has its password provided by the operating system. home_folder_path is set as Inherit for mike, so that it will use the group’s home folder path. If the group’s home_folder_path is defined as ${OS_HOME}, it will be retrieved from the operating system.
When SFTPPlus is started or running, and the configuration is still unchanged since installing, the log will show a large amount of entries regarding the IP address 0.0.0.0. This is the expected behavior. To quote wikipedia, “In the context of servers, 0.0.0.0 means ‘all IPv4 addresses on the local machine’. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.”
For accounts authenticated via the operating system, the server can be configured to use the home folder path provided by the operating system. This is done by using the special value ${OS_HOME} as the configured path. The ${OS_HOME} placeholder is also available for groups, so multiple accounts can be configured using this placeholder.
Here is an example:
[some_group]
enabled = yes
type = group
home_folder_path = ${OS_HOME}
[some_user]
enabled = yes
type = os
group = some_group
home_folder_path = Inherit
[other_user]
enabled = yes
type = os
group = other_group
home_folder_path = ${OS_HOME}
To generate a valid certificate, the Common Name (CN) fields should be set to the server’s address (for server certificates) or the client’s user name (for client certificates).
holder.
need to validate the identity of the certificate’s holder.
First of all, you will need to create pairs of self-signed certificates and keys for the client and the server.
SSL certificate-based authentication allows clients to authenticate using user name and SSL certificate pair credentials. A password is no longer required in this case.
To enable SSL certificate-based authentication, you will have to set the following option inside the FTP/FTPS service configuration section (located by default in configuration/server.ini):
enable_ssl_certificate_authentication = Yes
This option is enabled by default, so you should already have this option set.
A valid SSL certificate should have the value of the Common Name (CN) field match the authenticated user name.
To disable SSL certificate-based authentication, you will have to set the following option inside the FTP/FTPS service configuration section (located by default in configuration/server.ini):
enable_ssl_certificate_authentication = No
After disabling SSL certificate-based authentication, you must check that password-based authentication is enabled, otherwise clients will have no other authentication method available to log in.
The Local Manager service provides a tool for generating new SSH keys or converting existing SSH keys.
Please refer to the SSH service configuration page.
At this moment, the SFTPPlus SFTP service does not support PKI X.509 SSL certificate authentication. SSL certificate authentication, together with self-signed SSL certificates are supported using the FTPS protocol. For more information, please refer to FTP/FTPS service configuration page.
The reason why SSL certificate authentication is not available for SFTP is that this is not a standard authentication method for the SSH and the SFTP protocols.
Implementing such a feature would involve breaking the compatibility of SFTPPlus with all other standard SFTP clients and forcing customers to use our non-standard SFTPPlus SFTP Client implementation.
We are aware that in some cases some partners are willing to make this trade-off. This is why we plan to add SSL certificate support for SFTP in the near future.