GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages
FTPD(8) FreeBSD System Manager's Manual FTPD(8)

ftpdInternet File Transfer Protocol server

ftpd [-46ADdEhMmOoRrUuvW] [-L logparam [-L logparam]] [-l [-l]] [-a addrparam [-a addrparam]] [-P port] [-p file] [-S logtype] [-T maxtimeout] [-t timeout] [-u umask] [-X logtype] [-z secparam [-z secparam [...]]]

The ftpd utility is the Internet File Transfer Protocol server process. The server uses the TCP protocol and listens at the port specified with the -P option or in the “ftp” service specification; see services(5).

Available options:

When -D is specified, accept connections via AF_INET socket.
When -D is specified, accept connections via AF_INET6 socket.
Allow only anonymous ftp access.
Configure network addresses. This option may be specified several times to set different address parameters. The possible values of addrparam are:
When -D is specified, accept connections only on the specified address. The value of the address parameter may be a numeric host address string (a dotted-decimal IPv4 address or an IPv6 hex address) or a symbolic host name.
Override the IP address that will be advertised to IPv4 clients in response to the PASV and LPSV commands. The address parameter describes an IPv4 family address.

When -D is not specified, the value of the address string may be a numeric IPv4 family address in the dotted-decimal notation or a symbolic host name, which will be resolved after the connection of the client. If -D is specified, only the numeric host address string is supported.

With this option set, ftpd will detach and become a daemon, accepting connections on the FTP port and forking children processes to handle them. This is lower overhead than starting ftpd from inetd(8) and is thus useful on busy servers to reduce load.
Debugging information is written to the syslog using LOG_FTP.
Disable the EPSV and EPRT commands. This is useful for servers behind older firewalls.
Disable printing host-specific information, such as the server software version or hostname, in server messages.
Set the logging parameters. This option may be specified many times to enable different logging features. The possible values of logparam are:
Pathnames of the transferred files in the anon xferlog(5) format (used for anonymous file downloads) will be interpreted as pathnames in the real file system.
If the FTP session has been chrooted, pathnames of the transferred files in the original and extended wu-ftpd xferlog(5) formats will be interpreted as pathnames in the real file system.

In case of the chrooted FTP session the only way to obtain a pathname in the real file system is to concatenate the known pathname of the chroot point and a pathname of a file in the current chrooted environment. Therefore the anon-abs and wu-abs parameters should be used with the caution that ftpd unable to determine renames of the chroot point in the real file system if they occur after the change of the session root.

Each successful and failed ftp(1) session is logged using syslog with a facility of LOG_FTP. The authentication events in some cases are logged with a facility of LOG_AUTH or LOG_AUTHPRIV.

If this option is specified twice, the retrieve (get), store (put), append, delete, make directory, remove directory and rename operations and their filename arguments are also logged.

The format, in which the information about the retrieve (get), store (put) and append operations will be logged, may be changed to the wu-ftpd style xferlog(5) one with help of the -X option.

Prevent anonymous users from creating directories.
Permit anonymous users to overwrite or modify existing files if allowed by file system permissions. By default, anonymous users cannot modify existing files; in particular, files to upload will be created under a unique name.
Put server in write-only mode for anonymous users only. RETR is disabled for anonymous users, preventing anonymous downloads. This has no effect if -o is also specified.
Put server in write-only mode. RETR is disabled, preventing downloads.
When -D is specified, accept connections at port, specified as a numeric value or service name, instead of at the default “ftp” port.
When -D is specified, write the daemon's process ID to file.
With this option set, ftpd will revert to historical behavior with regard to security checks on user operations and restrictions on PORT requests. Currently, ftpd will only honor PORT commands directed to unprivileged ports on the remote user's host (which violates the FTP protocol specification but closes some security holes).
Put server in read-only mode. All commands which may modify the local file system are disabled.
With this option set, ftpd logs all file transfers to the file /var/log/ftpd when this file exists. This file name may be overridden in the virtual hosting configuration file. The possible values of logtype are:
Server logs only anonymous file downloads in its own xferlog(5) format.
Log all file transfers in the original wu-ftpd xferlog(5) format.
Log all file transfers in the extended wu-ftpd style xferlog(5) format. In this case the information about restarted downloads and about appends will also be available.
A client may also request a different timeout period; the maximum period allowed may be set to timeout seconds with the -T option. The default limit is 2 hours.
The inactivity timeout period is set to timeout seconds (the default is 15 minutes).
This option instructs ftpd to use data ports in the default port range instead of in the high port range. Such a change may be useful for some specific firewall configurations.

Please note that the conception of various port ranges, whose are used to selecting a local port number, may not be implemented in some operating systems. Also both port ranges may be identical by default. See the NOTES section for more information about the implementation of this feature.

The default file creation mode mask is set to umask, which is expected to be an octal numeric value. Refer to umask(2) for details. See also the NOTES section for the information about the implementation of this feature in ports of this ftpd.
A synonym for -d.
Do not log FTP sessions to /var/log/wtmp.
Log all file transfers to the syslog in the wu-ftpd style xferlog(5) format. File transfers will be logged regardless of the logging state which is set by the -l option, but if the -l option is specified twice, the information about the retrieve (get), store (put) and append operations will be logged in this format.

The possible values of logtype are:

Log all file transfers in the original wu-ftpd format.
Log all file transfers in the extended wu-ftpd style format. In this case the information about restarted downloads and about appends will also be available.
Configure the TLS/SSL security mechanism. This option may be specified many times to set different security parameters. The possible values of secparam are:

Security policy options

Don't fall back into the non-secure mode if the TLS/SSL handshake fails.
Disable the TLS/SSL encryption at all and allow only non-secure clients.
Protocol negotiation options
 
Use only the RFC2228-compliant FTP-TLS negotiation mode; don't try to negotiate something different.
Use only the FTP-SSL compatibility mode (for early implementations of the FTP-SSL upgrade); don't try to negotiate something different.

By default both FTP-TLS and FTP-SSL security extensions and the non-secure standard mode are allowed.

Options inside both groups above are mutually exclusive, but a protocol negotiation option may be used after a security policy option to specify the security extension to be used (in this case it overrides the nosecure option and turns on the TLS/SSL encryption with the selected negotiation mode).

User policy options

Require the TLS/SSL encryption for non-anonymous users.
Disable the TLS/SSL encryption for anonymous users.

X.509 certificate options

Basic options

Set the X.509 certificate verification level. Possible values are:
0 (default) - the server will not send the client certificate request to the client, so the client will not send the certificate.
1 - the server sends the client certificate request to the client. The certificate returned (if any) is checked. If the verification process fails, the TLS/SSL handshake is immediately terminated.
2 - the server sends the client certificate request to the client. If the client did not return the certificate or if the verification process fails, the TLS/SSL handshake is immediately terminated.
The certificate to use. This certificate will be passed to the client. If it is not specified, it will be default to ftpd.pem.
The private key that matches the certificate specified by the cert option. If this is not specified (but cert is), the cert=certfile will be searched for the private key. Both files are assumed to be in PEM format. Default is ftpd.pem.

If the client certificate is presented for the control connection, ftpd expects that the certificate presented for the data connection must match with it.

Alternate verify locations

The file that contains the trusted CA certificate in PEM format. The file can contain several CA certificates.
The directory that contains trusted CA certificates in PEM format. Each file contains one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number.
The file that contains the Certificate Revocation List (CRL) in PEM format. The file can contain several CRLs.
The directory that contains CRLs in PEM format. Each file contains one CRL. The files are looked up by the issuer name hash value, which must hence be available. If more than one CRL with the same name hash value exist, the extension must be different (e.g. 9d66eef0.r0, 9d66eef0.r1 etc). The search is performed in the ordering of the extension number.

If none of both CAfile and CApath (or CRLfile and CRLpath) are specified, both cafile and capath (or crlfile and crlpath) will be set to default values, otherwise each of cafile and capath (crlfile and crlpath) will be set to the specified value or blank if not specified. The default values are cert.pem and crl.pem files for cafile and crlfile, respectively, and certs/ subdirectory in OpenSSL directory is the default value for both capath and crlpath.

When looking up CA certificates, they will be searched in cafile, then those in capath. Certificate matching is done based on the subject name, the key identifier (if present), and the serial number as taken from the certificate to be verified. If the first certificate which matching the parameters is found, the verification process will be performed.

CRLs are looked up in the similar order: they will be searched in crlfile, then those in crlpath. CRL matching is done based on the issuer name. If the first CRL for this issuer is found, the verification process will be performed.

X.509 certificate-based user authentication

Enable support for the X.509 certificate-based user authentication. Possible values of the authentication mode are:
0 (default) - only the standard (typically password-based) authentication is allowed.
1 - the certificate-based authentication is sufficient; the fallback to the standard authentication is allowed in case of failure.
2 - only the certificate-based authentication is allowed.
3 - both certificate-based and standard authentications are required.

The support for the user authentication that is based upon the authentication information obtained from X.509 certificates is possible only for TLS/SSL-enabled FTP clients; standard FTP clients will always be authenticated through the standard authentication procedure. This type of authentication implies that the server must obtain the certificate from the client, and hence the certificate verification level (described above) must have the non-zero value.

The client must still issue the login name. If the X.509 authentication was successful and the fallback to the standard authentication is not required, the user will be successfully authenticated without asking for the password.

If the certificate-based authentication was used and the standard authentication was not, PAM modules (see pam(8)) from the authentication management group will not be used. PAM modules from the account management group will always be used for all authentication modes. The login.conf(5) (see also the NOTES section) functionality is also will be used for all modes.

Relations between client certificates and system login names are guided by the /etc/x509.auth file. Each relation is defined by its own line that contains a number of fields separated by colons:

service
The name of the service associated with this entry. The ftpd utility uses the “ftpd” service name.
action
Specifies the action, which will be executed if the client information matches with corresponding fields of the configuration line. This field may be presented by one of the following keywords:
“allow” - the certificate is allowed to use the requested login name; the authentication procedure succeeds.
“deny” - the certificate is denied to use requested login name; the authentication procedure fails.
userlist
Contains a comma-separated list of login names those will be compared with the login name issued by the client.

If the login name begins with the `/' symbol, it designates a field of the X.509 client certificate that includes the User ID of the end user. This designation may be specified in two forms:
``/ObjType'' - the field "ObjType" will be extracted and used as the login name.
``//ObjType[/domain.name]'' - the field "ObjType" will be treated as an Internet email address. In this case the part of the email address before `@' symbol will be used as the login name; if ``domain.name'' is specified, the part after `@' symbol will be verified against it (the ``domain.name'' part is not case-sensitive).

If the login name is presented by the `*' symbol, it matches with any login name issued by the client.

certificate
Describes the X.509 client certificate that is authorized to use the userlist. If this field isn't starts with a directive, it contains the one line distinguished name (the certificate's subject name). The directives are:
``-r'' - the rest part is interpreted as a regular expression (see regex(3)) that describes the distinguished name and can match multiple certificates, each of which is authorized to use the userlist.
``-f'' - the rest part is interpreted as a file name that contains the X.509 certificate or a set of certificates in PEM format, each of which is authorized to use the userlist. For security reasons this file will be used for the authentication only if it is a regular file and is not a symbolic link. If the file name begins with the tilde character (`~'), then this symbol will be substituted by the login directory that is associated with the login name issued by the client.
``-p'' - this directive allows the usage of an external program to check the certificate. The rest part of the field is interpreted as the full file name of the program. The external authentication program must accept the login name and the certificate from stdin and return the results of the authentication (a reply code and the login name associated with the certificate) to stdout.

Lines beginning with the `#' symbol are ignored and can be used to include comments. The components of fields are case-sensitive (the exception is noted above); spaces are not ignored and are treated as parts of respective components. All fields are mandatory, lines with unrecognized tokens (keywords, directives, etc.) in one or more fields are ignored.

Fields of each line and userlists are proceeded from left to right. The file itself is proceeded line-by-line from top to bottom until the first match for the given service in the 'userlist' and 'certificate' fields with corresponding values those are provided by the client.

If the match is found, the 'action' field of the configuration line will be analized and the authentication procedure succeeds or fails depending to its value. If no match is found, the certificate-based user authentication fails.

Other TLS/SSL specific options

The cipher preference list. The cipherlist consists of one or more cipher strings separated by colons. The actual cipher string can take several different forms. It can consists of a single cipher suite. It can represent a list of cipher suites containing a certain algorithm, or cipher suites of a certain type.

Lists of cipher suites can be combined in a single cipher string using the + character. It is used as the logical and operation.

Each cipher string can be optionally preceded by the characters !, - or +. If ! is used then the ciphers are permanently deleted from the list. If - is used then the ciphers are deleted from the list, but some of all of them can be added again by later options. If + is used then the ciphers are moved to the end of the list. Additionally the cipher string @STRENGTH can be used at any point to sort the current cipher list in order of an encryption algorithm key length.

The following is the short list of permitted cipher strings and their meanings, see the accompanying documentation for more information.
DEFAULT - The default cipher list (determined at a compilation time).
ALL - All cipher suites except the ciphers those offering no encryption.
HIGH - "High" encryption cipher suites (those with key lengths larger than 128 bits).
MEDIUM - "Medium" encryption cipher suites (those using 128 bit encryption).
LOW - "Low" encryption cipher suites (those using 64 or 56 bit encryption algorithms but excluding export cipher suites).
EXP, EXPORT - Export encryption algorithms (including 40 and 56 bits algorithms).
TLSv1, SSLv3, SSLv2 - TLS v1.0, SSL v3.0 or SSL v2.0 cipher suites respectively.

The file where the TLS/SSL debugging information will be logged.
Turn on the TLS/SSL debugging code (it requires the logfile option).

Compatibility options

Allow switching of the protection state of data connections before the completed user login. By default this operation is disabled until the user will be successfully logged in, and it is allowed at any time after that.
Use "334" reply code in the FTP-SSL compatibility mode instead of "234". It may be useful as a workaround for some early client implementations of the FTP-SSL upgrade.

The file /var/run/nologin (in FreeBSD) or /etc/nologin (in Linux, see also pam(8)) can be used to disable ftp access. If the file exists, ftpd displays it and exits. If the file /etc/ftpwelcome exists, ftpd prints it before issuing the “ready” message. If the file /etc/ftpmotd exists, ftpd prints it after a successful login. Note the motd file used is the one relative to the login environment. This means the one in ~ftp/etc in the anonymous user's case.

The ftp server currently supports the following ftp requests. The case of the requests is ignored. Requests marked [RW] are disabled if -r is specified.

ABOR abort previous command
ACCT specify account (ignored)
ALLO allocate storage (vacuously)
APPE append to a file [RW]
AUTH specify authentication/security mechanism
CDUP change to parent of current working directory
CWD change working directory
DELE delete a file [RW]
EPRT specify data connection port, multiprotocol
EPSV prepare for server-to-server transfer, multiprotocol
FEAT return list of supported extensions
HELP give help information
LIST give list files in a directory (“ls -lgA”)
LPRT specify data connection port, multiprotocol
LPSV prepare for server-to-server transfer, multiprotocol
MDTM show last modification time of file
MKD make a directory [RW]
MODE specify data transfer
NLST give name list of files in directory
NOOP do nothing
OPTS specify the behavior of FTP commands
PASS specify password
PASV prepare for server-to-server transfer
PBSZ specify protection buffer size
PORT specify data connection port
PROT specify data connection protection level
PWD print the current working directory
QUIT terminate session
REST restart incomplete transfer
RETR retrieve a file
RMD remove a directory [RW]
RNFR specify rename-from file name [RW]
RNTO specify rename-to file name [RW]
SITE non-standard commands (see next section)
SIZE return size of file
STAT return status of server
STOR store a file [RW]
STOU store a file with a unique name [RW]
STRU specify data transfer
SYST show operating system type of server system
TYPE specify data transfer
USER specify user name
XCUP change to parent of current working directory (deprecated)
XCWD change working directory (deprecated)
XMKD make a directory (deprecated) [RW]
XPWD print the current working directory (deprecated)
XRMD remove a directory (deprecated) [RW]

The following non-standard or UNIX specific commands are supported by the SITE request.

UMASK change umask, e.g. ``SITE UMASK 002''
IDLE set idle-timer, e.g. ``SITE IDLE 60''
CHMOD change mode of a file [RW], e.g. ``SITE CHMOD 755 filename''
MD5 report the files MD5 checksum, e.g. ``SITE MD5 filename''
HELP give help information

Note: SITE requests are disabled in case of anonymous logins.

The remaining ftp requests specified in Internet RFC 959 are recognized, but not implemented. MDTM and SIZE are not specified in RFC 959, but will appear in the next updated FTP RFC. To avoid possible denial-of-service attacks, SIZE requests against files larger than 10240 bytes will be denied if the current transfer type is ASCII.

The ftp server will abort an active file transfer only when the ABOR command is preceded by a Telnet "Interrupt Process" (IP) signal and a Telnet "Synch" signal in the command Telnet stream, as described in Internet RFC 959. If a STAT command is received during a data transfer, preceded by a Telnet IP and Synch, transfer status will be returned.

The ftpd utility interprets file names according to the “globbing” conventions used by csh(1). This allows users to utilize the metacharacters “*?[]{}~”.

The ftpd utility authenticates users according to six rules.

  1. The login name must be in the user database and not have a null password (the exception is possible if PAM modules from the authentication management group are used to set up a template user account; see below). If a client is connected via TLS/SSL and the X.509 certificate-based authentication is sufficient, it will be used instead of the password-based one. Otherwise the standard authentication will be used.

    In this case a password must be provided by the client before any file operations may be performed. If the user has an S/Key key, the response from a successful USER command will include an S/Key challenge. The client may choose to respond with a PASS command giving either a standard password or an S/Key one-time password. The server will automatically determine which type of password it has been given and attempt to authenticate accordingly. See key(1) for more information on S/Key authentication. S/Key is a Trademark of Bellcore.

    See also the NOTES section for the information about built-in implementation of S/Key in ports of this ftpd.

    If pam(8) is used for the authentication, PAM modules from the authentication management group may set up some user account as the template. This user account will be used in all routines for whose the user account (the user record) in the system user database is mentioned, so an FTP user will have access privileges of this system user account.

  2. The login name must not appear in the file /etc/ftpusers, otherwise the login attempt will be refused without asking for a password.
  3. The user account name must not be a member of a group specified in the file /etc/ftpusers, otherwise the login attempt will be refused without asking for a password. Entries in this file interpreted as group names are prefixed by an "at" ‘@’ sign.
  4. The user account must have a standard shell returned by getusershell(3).
  5. If the user account name appears in the file /etc/ftpchroot, or the user account is a member of a group with a group entry in this file, i.e. one prefixed with ‘@’, the session's root will be changed to the directory specified in this file or to the user's login directory by chroot(2) as for an “anonymous” or “ftp” account (see next item). See ftpchroot(5) for a detailed description of the format of this file. This facility may also be triggered by enabling the boolean "ftp-chroot" capability in login.conf(5) (see also the NOTES section). However, the user must still supply a password. This feature is intended as a compromise between a fully anonymous account and a fully privileged account. The account should also be set up as for an anonymous account.
  6. If the user name is “anonymous” or “ftp”, an anonymous ftp account must be present in the user database (user “ftp”). In this case the user is allowed to log in by specifying any password (by convention an email address for the user should be used as the password). When the -S option is set, all transfers are logged as well.

In the last case, ftpd takes special measures to restrict the client's access privileges. The server performs a chroot(2) to the home directory of the “ftp” user. As a special case if the “ftp” user's home directory pathname contains the /./ separator, ftpd uses its left-hand side as the name of the directory to do chroot(2) to, and its right-hand side to change the current directory to afterwards. A typical example for this case would be /usr/local/ftp/./pub. In order that system security is not breached, it is recommended that the “ftp” subtree be constructed with care, following these rules:

~ftp
Make the home directory owned by “root” and unwritable by anyone.
~ftp/etc
Make this directory owned by “root” and unwritable by anyone (mode 555). The files pwd.db (see passwd(5)) and group(5) must be present for the ls(1) command to be able to produce owner names rather than numbers. The password field in passwd(5) is not used, and should not contain real passwords. The file ftpmotd, if present, will be printed after a successful login. These files should be mode 444.
~ftp/pub
This directory and the subdirectories beneath it should be owned by the users and groups responsible for placing files in them, and be writable only by them (mode 755 or 775). They should be owned or writable by “ftp” or its group, otherwise guest users can fill the drive with unwanted files.

If the system has multiple IP addresses, ftpd supports the idea of virtual hosts, which provides the ability to define multiple anonymous ftp areas, each one allocated to a different internet address. The file /etc/ftphosts contains information pertaining to each of the virtual hosts. Each host is defined on its own line which contains a number of fields separated by whitespace:

hostname
Contains the hostname or IP address of the virtual host.
user[:anondir]
Contains a user record in the system user database. As with normal anonymous ftp, this user's access uid, gid and group memberships determine file access to the anonymous ftp area. If anondir is specified, it determines the anonymous ftp area (to which any user is chrooted on login), otherwise the anonymous ftp area is determined by the home directory defined for the account, or by the directory specified in the ftpchroot(5) file.
statfile
File to which all file transfers are logged, which defaults to /var/log/ftpd.
welcome
This file is the welcome message displayed before the server ready prompt. It defaults to /etc/ftpwelcome.
motd
This file is displayed after the user logs in. It defaults to /etc/ftpmotd.

Lines beginning with a '#' are ignored and can be used to include comments.

Defining a virtual host for the primary IP address or hostname changes the default for ftp logins to that address. The 'user', 'statfile', 'welcome' and 'motd' fields may be left blank, or a single hyphen '-' used to indicate that the default value is to be used.

As with any anonymous login configuration, due care must be given to setup and maintenance to guard against security related problems.

The ftpd utility has internal support for handling remote requests to list files, and will not execute /bin/ls in either a chrooted or non-chrooted environment. The ~/bin/ls executable need not be placed into the chrooted tree, nor need the ~/bin directory exist.

/etc/ftpusers
List of unwelcome/restricted users.
/etc/ftpchroot
List of normal users who should be chroot'd.
/etc/ftphosts
Virtual hosting configuration file.
/etc/ftpwelcome
Welcome notice.
/etc/ftpmotd
Welcome notice after login.
/etc/x509.auth
Configuration file for relations between client certificates and system login names.
/var/run/nologin or /etc/nologin
Displayed and access refused.
/var/log/ftpd
Log file for all file transfers.

ftp(1), ftps(1), key(1), openssl(1), umask(2), getusershell(3), regex(3), ftpchroot(5), login.conf(5), xferlog(5), inetd(8), pam(8), syslogd(8)

The default value of the umask defined in ftpd is 022 (write access for the owner only). In FreeBSD the value of the umask specified through the -u command-line option (and the default value too) may be overridden by the login.conf(5).

The -U command-line option instructs ftpd to use data ports in the range of IP_PORTRANGE_DEFAULT instead of in the range of IP_PORTRANGE_HIGH. This option is virtual no-op in FreeBSD 5.0 and above (both port ranges are indentical by default). The conception of various port ranges is not implemented in Linux, so in this operating system the -U option has no effect. See ip(4) in FreeBSD or ip(7) in Linux for more information about available port ranges.

The support for the login.conf(5) is available only in BSD systems. The general part of the capabilities of the login.conf(5) may be implemented with help of pam(8). The capabilities, those are distinctive to the ftpd, are also implemented with help of its own functionality.

Currently the support for S/Key is not available in both FreeBSD and Linux ports.

The server must run as the super-user to create sockets with privileged port numbers. It maintains an effective user id of the logged in user, reverting to the super-user only when binding addresses to sockets. The possible security holes have been extensively scrutinized, but are possibly incomplete.

The ftpd utility appeared in 4.2BSD. IPv6 support was added in WIDE Hydrangea IPv6 stack kit.

Modifications for TLS/SSL support, RFC2228 features and Linux port were made by Nick Leuta <skynick@mail.sc.ru>

November 1, 2004 FreeBSD 14.3-RELEASE

Search for    or go to Top of page |  Section 8 |  Main Index

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with ManDoc.