This page contains information about the usage and behaviour of the FTP commands implemented by the FTP service/server and the FTP location/client.
The FTP/FTPS implementation is designed to follow the RFCs as much as possible and mimic the behaviour found in the VSFTPD implementation without sharing any source code.
Our goal for SFTPPlus is to implement all FTP commands described in dedicated RFC specifications.
Below is a list with current supported commands. Most commands are defined in the original RFC 959. In RFC 5797 you can check the exact RFC associated with a command.
The list of available SITE commands is:
For every command requested by the FTP client, SFTPPlus will reply with a completion code and a human readable text.
Based on the FTP standard (RFC 959), well behaved FTP clients should only look at the completion code and ignore the human readable text. The codes are for use by programs and the text is usually intended for human users to review the programs’ activity.
While the completion codes are well documented in the FTP standards, the content of the human readable text is left undocumented.
In SFTPPlus the content of the human readable text is not documented and can’t be configured. To improve compatibility with the FTP clients we try to follow the human readable messages produced by the VSFTPD open source FTP/FTPS server. Please report any inconsistency in the content of the human readable text sent together with the completion codes.
SFTPPlus supports only the ASCII and IMAGE/BINARY data types.
When no explicit data type is requested by the client-side, the server will consider the data type as IMAGE/BINARY.
The default data type can be changed using the FTP service configuration.
Note
The RFC 959 defines the default type as ASCII, but in SFTPPlus the default mode is IMAGE to match the behaviour found for the SFTP and HTTPS, the implementation found in the previous versions of SFTPPlus, and the VSFTD implementation.
When the IMAGE/BINARY data type is used, files are transferred as they are, without any changes to their content.
When the ASCII data type is used, the source peer will convert any new line delimiters to the standard FTP delimiter CRLF.
Note
In ASCII mode, the SIZE command will return the size of the file as stored on the server and not as transferred with new line conversion as mandated by the RFC 959 for ASCII mode transfers.
This is done to prevent denial of service attack (DoS) and to match the behavior found in the VSFTPD implementation.
Since SFTPPlus is designed as a cross platform solution, when SFTPPlus is the source of the transfer (for example when responding to the RETR command) it will convert both Unix and Windows new line delimiter to the FTP new line delimiter.
When SFTPPlus acts as the destination of the transfer, it will convert the new lines only when running on Unix and Linux as the FTP and Windows new line delimiter are the same.
The FTP/FTPS service can be configured to pretend that ASCII mode is provided but to transfer the actual data based on IMAGE/BINARY mode. For more details check the configuration section.
SFTPPlus supports globbing / wildcards expressions for both LIST and NLST commands.
The following wildcards are available:
- * - matches any number of characters
- ? - matches exactly one character
- [ and ] - matches exactly one character from the group of characters listed inside the brackets.
Check the following examples to get a better understanding of globbing and the usage of wildcards.
All examples are based on the following folder structure:
a_file.txt
other_extension.file.doc
other_file.txt
some_empty_folder
some_file1.txt
some_file11.txt
some_file2.txt
some_folder
some_folder/file2.txt
Running LIST * will return the following members:
a_file.txt
other_extension.file.doc
other_file.txt
some_empty_folder/
some_file1.txt
some_file11.txt
some_file2.txt
some_folder/
Note
some_folder/file2.txt is excluded from the result, since the match is not recursive.
Running LIST some_empty_folder/* will return an empty result set.
Running LIST *.txt will return any file or folder ending with .txt:
a_file.txt
other_file.txt
some_file1.txt
some_file11.txt
some_file2.txt
Running LIST some_file?.txt will return:
some_file1.txt
some_file2.txt
Note
some_file11.txt is excluded from the result since ? matches a single character only.
Running LIST [ao]* will return any file or folder starting with a or o:
a_file.txt
other_extension.file.doc
other_file.txt
Running LIST [bc]* will return an empty result set since no file or folder starts with b or c.
Globbing will not work if applied recursively. Any of the commands listed below will result in a failure:
LIST */file*
LIST some_*/file2.txt
On Unix and Linux systems, the server supports the SITE CHMOD command, which allows changing permissions for a target path.
SITE CHMOD is not specified in the FTP standard and it is not available on Windows, since permissions on Windows are different from those on Unix/Linux.
The syntax for the SITE CHMOD command is:
SITE CHMOD mode path
where mode is an octal permission mode and path is the targeted path.
To change the permissions to 644 for file some/file name.txt the command is:
SITE CHMOD 644 some/file name.txt
Note
The server will only consider the significant bits from the requested permissions and ignore any extra bits. This is why setting a mode like 10000644 will succeed.
When the SYST command is issued to the server, the FTP client wants to know the operating system type used by the server. To prevent any potential security issue and to keep the operating system anonymous, the server will always respond with a generic UNIX Type: L8 answer.
Based on FTP specifications, all commands are sent using a dedicated command channel. Command responses are sent by the server using the same channel.
All data transfer, including folder listing, are sent over a different data channel. Only a single data channel can be active at any given time.
This is how the FTP implementation behaves when for example it receives both PASV and PORT command for a data channel which was not yet used:
< PASV
> 227 Entering Passive Mode (127,0,0,1,35,40).
> PORT 127,0,0,1,35,41
FTP COMMAND PAUSE HERE UNTIL PASV REQUEST TIMES OUT
< 200 PORT OK
< 125 Data connection already open, starting transfer
drwxrwxr-x 3 1001 1001 4096 Jul 24 12:00 man
When a data channel is active and the client requests a new data channel, the previous data channel is forcibly closed, even if already connected, and a new data channel is created.
When the FTP/FTPS service is accessed from behind a NAT, using the standard PASV commands, clients will get a response containing the server internal IP address, rather than the external address used by the NAT server. This is not an implementation error in SFTPPlus, but a design problem of the standard PASV command, which was defined in 1985 in RFC 959.
RFC 2428 was created to solve this problem and it adds EPSV command (extended PASV). Whenever possible, FTP clients are encouraged to use EPSV rather than PASV and EPRT rather than PORT command.
In the case that you have legacy FTP clients without EPSV support to connect to your FTP / FTPS server from behind the NAT, the FTP service configuration provides the passive_address configuration option as a way to work around this problem. For more details please check the FTP service configuration page.
When passive_address is defined and you have FTP clients which connect from the same LAN (not passing the NAT), they will still get the NAT IP address in PASV responses. As a way to get around this, you can create a new FTP service, on a different port, dedicated to internal LAN clients. For this new service, leave the passive_address configuration option empty.
For active connection, a FTP or FTPS server will actually initiate the data channel connection as a TCP client.
For these connection types, the destination address and port are specified by the client as part of the PORT / EPRT commands.
By default, for these connections, SFTPPlus will use any source address or source port, letting the operating system choose the actual value. Most operating systems will use a port number in the range allocated to the ephemeral ports.
Some (legacy) FTP clients require that all active data channel connections are initiated from port 20 or a different configurable port.
You can also use a single source port in the case when the outgoing traffic should be filtered by the firewall.
SFTPPlus can be configured to use a specific source port number. For more details please check the FTP service configuration page.
SFTPPlus will always use the UTF-8 encoding for file names and paths.
Support for UTF-8 is advertised by the FTP server in the response of the FEAT command and OPTS UTF8 command is supported as well.
The FTP client will inform the server about UTF-8 support by sending the OPTS UTF8 command, if UTF-8 support is advertised by the server.
If server supports the CLNT command, the client will also issue the CLNT command, before issuing the OPTS command.
The CCC command is defined in RFC 2228 and RFC 4217.
If the server and client support the CCC command, it can be used to revert a control channel connection protected using SSL/TLS to plain text mode, no security.
The usage of the CCC decreases the security of the connection.
Most firewall devices can only inspect unencrypted PASV/PORT commands in order to open the expected data port (port negotiated by server-client) in an automatic manner.
The usage of the CCC can be avoided by defining a static port range for the data connections.
If static port range for the data connection does not meet your requirements, the usage of the CCC command can be used to implement an authentication process which is still secured by TLS/SSL.
In most of the scenarios, the CCC command is used to shut down the SSL/TLS layer after the authentication step. The rest of the control channel communication will be done over an unencrypted connection.
On the server-side, when the CCC command is requested by a client, the SFTPPlus server will always initiate the SSL/TLS shutdown, after the reply is sent to the client. That is, the reply to the CCC command is still sent over a protected connection.
On the client-side, while the CCC command takes no argument, it can be implemented in two modes:
passive mode - client-side will not initiate the shutdown, but instead wait for the server-side to do it. Will not reply to the shutdown from the server
and waits for a reply from the server, before sending further commands.