is the
Internet File Transfer Protocol
server process. The server uses the
protocol
and listens at the port specified in the
service specification; see
Available options:
Permit only anonymous ftp connections or accounts listed in
Other connection attempts are refused.
Debugging information is written to the syslog using LOG_FTP.
With this option set,
will detach and become a daemon, accepting connections on the FTP port and
forking child processes to handle them. This has lower overhead than
starting
from
and is thus useful on busy servers to reduce load.
The server will use data ports in the high port range for passive connections.
This range is defined by the
and
defines in <netinet/in.h>. In
they are set to 49152 and 65535 respectively.
Each successful and failed
session is logged using syslog with a facility of LOG_FTP.
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.
Enables multihomed mode. Instead of simply using
for anonymous transfers, a directory matching the fully qualified name of
the IP number the client connected to, and located inside
is used instead.
Disable passive mode ftp connections. This is useful if you are behind
a firewall that refuses connections to arbitrary high numbered ports.
Many ftp clients try passive mode first and do not always react gracefully
to a server that refuses connections to the port it asked the client to
connect to.
Permit illegal port numbers or addresses for PORT command initiated connects.
By default
violates the RFC and thus constrains the PORT command to non-reserved ports
and requires it use the same source address as the connection came from.
This prevents the "FTP bounce attack" against services on both the local
machine and other local machines.
With this option set,
logs all anonymous transfers to the file
when this file exists.
Each concurrent
session is logged to the file
making them visible to commands such as
This option at present is unsupporte and will always silently fail.
A client may also request a different timeout period;
the maximum period allowed may be set to
seconds with the
option.
The default limit is 2 hours.
The inactivity timeout period is set to
seconds (the default is 15 minutes).
Change the default umask from 027 to
The file
can be used to disable ftp access.
If the file exists,
displays it and exits.
If the file
exists,
prints it before issuing the
message.
If the file
exists,
prints it after a successful login. If the file
exists in a directory,
prints it when that directory is entered.
The ftp server currently supports the following ftp requests.
The case of the requests is ignored.
The following non-standard or
specific commands are supported
by the
SITE request.
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.
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.
interprets file names according to the
conventions used by
This allows users to utilize the metacharacters
authenticates users according to five rules.
The login name must be in the password data base,
and not have a null password.
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
for more information on S/Key authentication. S/Key is a Trademark of
Bellcore.
The login name must not appear in the file
The user must have a standard shell returned by
If the user name appears in the file
the session's root will be changed to the user's login directory by
as for an
or
account (see next item). 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.
If the user name is
or
an
anonymous ftp account must be present in the password
file (user
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).
In the last case,
takes special measures to restrict the client's access privileges.
The server performs a
to the home directory of the
user.
In order that system security is not breached, it is recommended
that the
subtree be constructed with care, following these rules:
Make the home directory owned by
and unwritable by anyone (mode 555).
Make this directory owned by
and unwritable by anyone (mode 511).
This directory is required, and should contain at least a statically
linked copy of
Any programs in this directory should be mode 111 (executable only).
Make this directory owned by
and unwritable by anyone (mode 511).
The files
and
must be present for the
command to be able to produce owner names rather than numbers.
The password field in
is not used, and should not contain real passwords.
The file
if present, will be printed after a successful login.
These files should be mode 444.
Make this directory mode 555 and owned by
This is traditionally where publically accessible files are
stored for download.
FILES
List of unwelcome/restricted users.
List of normal users who should be chroot'd.
Welcome notice.
Welcome notice after login.
Displayed and access refused.
List of users on the system.
Log file for anonymous transfers.
SEE ALSO
BUGS
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.
