This page describes the configuration options available for the FTP / FTPS service.
SFTPPlus provides two ways for securing FTP transfers.
Explicit FTPS is the most widely used method. The connections for Explicit FTPS are started just like normal FTP connections. After the initial connection, the FTP client can ask the server to switch to the secured Explicit FTPS mode.
The Explicit FTPS service can share the same TCP port with the non-secured FTP service. This is why the FTP and Explicit FTPS protocols are configured in SFTPPlus as a single service, using the ftp protocol.
A single service using the ftp protocol can be configured to allow only unsecured FTP connections, to allow only secured Explicit FTPS connections, or to allow both secured and unsecured connections.
Implicit FTPS is a method in which the client is required to initiate a connection using an SSL/TLS handshake. All connections not initiated using an SSL/TLS handshake are dropped. This does not allow sharing the same TCP port with a non-secured FTP service, thus the Implicit FTPS service requires a dedicated port.
For more details, please check the dedicated FTPS article from Wikipedia.
Multiple FTP services can share the same set of SSL keys and certificates. In fact, for a valid SSL configuration of multiple services using the same address on different ports, you actually have to use the same SSL certificate.
When the FTPS protocol is used, the configured SSL certificate must be issued with the same Common Name (CN) as the address used by the FTPS clients to connect to the server.
| Optional: | Yes |
|---|---|
| Default value: | Welcome to the FTP/SFTP Service. |
| Values: |
|
| From version: | 1.6.0 |
| To version: | None |
| Description: | When FTP/FTPS clients connect to the server, the server will greet them with this message. The message will automatically include the product name and version. If you want to hide the product name and version, start the message with the > character. If you don’t want to have any text displayed as part of the welcome message, configure it as >. |
| Optional: | Yes |
|---|---|
| Default value: | All available ports provided by the operating system. |
| Values: |
|
| From version: | 1.7.0 |
| To version: | None |
| Description: | When FTP/FTPS clients are requesting a passive transfer, the server will open a new connection that will be used for sending or receiving files from the client. By default, the server will use a random port number for the newly created connection. For example, to set a range of ports starting from 1500 and ending at port 2000, set the value to ‘1500 - 2000’, as in the following example:
To use all available ports, do not define this or set it to 0 - 0:
Note passive_port_range is designed to help with firewalled configurations, but to some extent it is also a mechanism to limit the number of concurrent connections to the server. While this option is specific to the FTP protocol, there is also a generic option, “maximum_concurrent_connections”, available to all protocols. |
| Optional: | Yes |
|---|---|
| Default value: | 0 |
| Values: |
|
| From version: | 3.6.0 |
| Description: | Source port used by the FTP service to initiate the active connections for the PORT or the EPRT requests. The source address is the same as address used to listen for incoming control connections. When set as 0, a random source port is used. Note On Linux and Unix systems, elevated privileges are required to initiate connection from source ports below 1024. |
| Optional: | Yes |
|---|---|
| Default value: | Disabled |
| Values: |
|
| From version: | 2.9.0 |
| Description: | IP address advertised by the FTP service in the passive PASV request. When left empty, the service will automatically detect server address. When set to a single IP address, it will use that address in all PASV requests, regardless of the client’s source IP. Note This option is ignored for EPSV requests. |
| Optional: | Yes |
|---|---|
| Default value: | 30 |
| Values: |
|
| From version: | 1.8.2 |
| To version: | None |
| Description: | Specifies the timeout, in seconds, after which an inactive data channel is disconnected. For this number of seconds, the service will only act upon the data channel, without disconnecting the command channel. |
| Optional: | Yes |
|---|---|
| Default value: | no-certificate-defined |
| Values: |
|
| From version: | 1.6.0 |
| To version: | None |
| Description: | The certificate file can contain both the certificate and the private key, in which case you don’t need to set the path to the private key file. |
| Optional: | Yes |
|---|---|
| Default value: | Disabled |
| Values: |
|
| From version: | 1.6.0 |
| To version: | None |
| Description: | If the file specified by the ssl_certificate option already contains the private key, this option can be omitted. |
| Optional: | Yes |
|---|---|
| Default value: | Disabled |
| Values: |
|
| From version: | 1.7.19 |
| To version: | None |
| Description: | This is used when the private SSL key is stored as an encrypted file. |
| Optional: | Yes |
|---|---|
| Default value: | Disabled |
| Values: |
|
| From version: | 1.6.0 |
| To version: | None |
| Description: | Only clients using certificates signed by one of these certificate authorities will be permitted to connect to this server using secured connections. The certificate authority file should be stored in PEM format. Leave it empty or set it as Disabled to disable checking the issuer for peer’s certificates. When certificate authority check is disabled, connection peers are not required to send a certificate. If the peer sends a certificate, it is ignored. |
| Optional: | Yes |
|---|---|
| Default value: | Disabled |
| Values: |
|
| From version: | 1.6.0 |
| To version: | None |
| Description: | It defines the locations from where one or more CRLs will be loaded. Multiple CRLs are defined as a comma separated list. It supports local files in both absolute and relative paths. Retrieving the CRL over HTTP is also supported. The HTTP request is done using non-persistent HTTP/1.1 connections. CRL distribution points (CDP) are supported by using the crl-distribution-points configuration value. When CRL distribution points are configured, the server-side certificate defined at ssl_certificate needs to have the CDP extension. The CDP advertised in the server-side certificate is loaded at startup in order to validate the configuration. The distribution points configuration is mutually exclusive with local file or HTTP url configurations. When the certificate revocation list is configured to use CDP, all other configured CRL location are ignored. Note HTTP redirection is not yet supported. Set it to Disabled, to disable certificate revocation checks. The certificate revocation list can only be used when the service is configured with CA certificates stored in a single file in PEM format. When multiple or chained CA certificates are configured the CRL is only checked for the peer’s certificate and not for the CA certificate or for an intermediate CA. Note CDP publishing Delta CRL are not supported. Note If the certificate defines multiple HTTP based distribution points in the CDP extension, only the first HTTP URI is used. All non HTTP or the other HTTP URIs are ignored. The CRL file should be stored in PEM or DER format. Note This option is ignored if ssl_certificate_authority is not enabled. |
| Optional: | Yes |
|---|---|
| Default value: | 0 |
| Values: |
|
| From version: | 2.8.0 |
| To version: | None |
| Description: | When set to 0, the CRL file is initially loaded at startup and then loaded again after the Next Update field advertised in the CRL. If the Next Publish extension is present in the CRL and this option is set to 0 the CRL will be loaded again at the date and time specified in the Next Publish extension. If the CRL does not advertise the Next Update field you will have to configure a number of seconds after which the CRL should be reloaded, otherwise you will get a configuration error. It can be configured with the number of seconds after which the local CRL file should be read again. For example, a value of 86400 means the server will re-read the CRL after one day. For more details about the CRL reloading see the documentation for CRL reloading rules Note This option is ignored if ssl_certificate_authority is not enabled. |
| Optional: | Yes |
|---|---|
| Default value: | ALL:!RC4:!DES:!MD5:!EXP |
| Values: |
|
| From version: | 1.7.4 |
| To version: | None |
| Description: | The format for this value is the same as the one used for defining the OpenSSL cipher list. More information can be found at the following URL: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT |
| Optional: | Yes |
|---|---|
| Default value: | tlsv1 tlsv1.1 tlsv1.2 |
| Values: |
|
| From version: | 1.7.4 |
| To version: | None |
| Description: | Currently, the following methods are officially supported:
SSLv3 is still supported but highly discouraged, due to the SSLv3 POODLE vulnerability. In the case that you need to interact with an old SSL implementation that only supports SSLv3, it is highly recommended to force the usage of the non-CBC cipher RC4-SHA by configuring ssl_cipher_list: RC4-SHA. Support for SSLv3 will be removed in future versions. SSLv2 is no longer supported since it is not secure.
|
| Optional: | Yes |
|---|---|
| Default value: | 300 |
| Values: |
|
| From version: | 1.7.19 |
| To version: | None |
| Description: | The service will close the connection if a client connection is idle for a configurable amount of time. |
| Optional: | Yes |
|---|---|
| Default value: | 10000 |
| Values: |
|
| From version: | 1.7.19 |
| To version: | None |
| Description: | Maximum number of allowed concurrent connections for this service. This limit is imposed by each service, and it is not a global limit for all services active on the server. |
| Optional: | Yes |
|---|---|
| Default value: | No |
| Values: |
|
| From version: | 1.6.0 |
| To version: | None |
| Description: | If the FTPS protocol is disabled, no secured connections are accepted. This will only enable Explicit FTPS secure connections, but will not enforce clients to use secured connections. Dedicated configuration options are provided for this purpose. Not available for the Implicit FTPS protocol. |
| Optional: | Yes |
|---|---|
| Default value: | Yes |
| Values: |
|
| From version: | 1.7.4 |
| To version: | None |
| Description: | Enable authentication based on user name and password credentials. |
| Optional: | Yes |
|---|---|
| Default value: | Yes |
| Values: |
|
| From version: | 1.7.4 |
| To version: | None |
| Description: | SSL certificate-based authentication allows clients to authenticate using a pair of user name and SSL certificate credentials. A password is no longer required. A valid SSL certificate should have the value of the Common Name (CN) field match the authenticated user’s name. When the SSL certificate-based authentication is disabled, you must check that password-based authentication is enabled, otherwise clients will have no authentication method available. |
| Optional: | Yes |
|---|---|
| Default value: | Yes |
| Values: |
|
| From version: | 1.7.18 |
| To version: | None |
| Description: | The server can be configured to force the user to establish a secured connection before sending account credentials (eg. user name and password). If the server is configured to only allow secured authentication and not to enforce securing generic commands, after a successful authentication, users can send the Clear Command Channel (CCC) command to revert the command channel to an unsecured transport. This will allow firewall or other tools (eg. FTP audit tools) to parse the commands issued within an FTP session. Not available for Implicit FTPS protocol, where secured authentication is always enforced due to the protocol’s specification. |
| Optional: | Yes |
|---|---|
| Default value: | No |
| Values: |
|
| From version: | 1.6.0 |
| To version: | None |
| Description: | When secure command channel is forced, any attempt to send unencrypted commands will be rejected. When this is set to Yes, ftps_force_secured_authentication values will be ignored and the server will always require a secured command channel. This option will be ignored if Explicit FTPS is not enabled. Not available for Implicit FTPS protocol, where secured command is always enforced due to protocol specification. |
| Optional: | Yes |
|---|---|
| Default value: | Yes |
| Values: |
|
| From version: | 1.6.0 |
| Description: | If FTPS secure data channel is forced, any attempt to initiate an unsecured data connection / transfer will be rejected. This option will be ignored if FTPS is not enabled. Not available for Implicit FTPS protocol, where data command is always enforced due to protocol specification. |
| Optional: | Yes |
|---|---|
| Default value: | No |
| Values: |
|
| From version: | 3.8.0 |
| Description: | This option allows configuring the FTP service to pretend that ASCII mode is supported, but to transfer the data in BINARY/IMAGE mode. |
| Optional: | Yes |
|---|---|
| Default value: | No |
| Values: |
|
| From version: | 3.10.0 |
| Description: | This option defines whether to use ASCII as the data type for the case in which the client does not explicitly ask for specific data type. Set it to Yes to use ASCII/text as the default data type. Set it to No to use IMAGE/binary as the default data type. |