|Professional FTP Daemon FAQ|
This section is being re-written due to major structural changes to the SQL module prior to 1.2.0
Security, pure and simple. PAM is the most secure (or securable) of the available authentication systems. Many of the issues and configuration hints for PAM are contained in README.PAM which is bundled with the server source and in the various packaged builds. To use /etc/passwd manual compilation will be required with the configure script being run with the --without-pam flag. Unless the PAM subsystem is properly configured authentication will fail.
Standard /etc/passwd lookups
Indvidual passwd/group files for each virtual
If these don't fit in with your system then writing a custom module or using such as the "ld.so.preload" approach to intercept getpwbynam() system calls works happily with ProFTPD.
Generally these problems will be cured by either disabling PAM completely or by ensuring that these directives are set
PersistentPasswd off AuthPAMAuthoritative off
Check the spelling it should be AuthPAMAuthoritative not AuthPAMAuthorative or any other variation.
There is a README.Pam in the top directory of the ProFTPD install directory :
#%PAM-1.0 auth required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so session required /lib/security/pam_pwdb.so
SuSE appears to uses pam_unix rather than pam_pwdb which is the Redhat approach. All references to pam_pwdb should be replaced with "pam_unix" on SuSE systems.
The following fragment is reported to work fine on SuSE 6.2/etc/pam.d/ftpd #%PAM-1.0 # Uncomment this to achieve what used to be ftpd -A. # auth required /lib/security/pam_listfile.so item=user sense=allow file=/etc/ftpchroot onerr=fail auth required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed auth sufficient /lib/security/pam_ftp.so auth required /lib/security/pam_unix.so auth required /lib/security/pam_shells.so account required /lib/security/pam_unix.so password required /lib/security/pam_unix.so session required /lib/security/pam_unix.so
FreeBSD does not support PAM session directives. If you remove the following line from the FreeBSD section of README.PAM, PAM should work properly under recent versions of FreeBSD.ftp session required pam_unix.so try_first_pass
Check that the /etc/pam.d/ftp file exists on the system and is configured as detailed in README.PAM
Currently AuthPAMAuthoritative defaults on "ON" resulting in login failures if PAM cannot authenticate the user. This breaks the AuthUserFile directive as it never gets a chance to authenticate the user unless the AuthPAMAuthoritative directive is set to "OFF"
The reasoning behind the current default is to ensure that the system is secure by default requiring that the admin explicitly and knowingly has to disable it. There are discussions underway which may result in the directive flipping to a default of "Off" if AuthUserFile is specified.
Note: as of the current CVS and the forthcoming pre9 release the default has changed to "Off"
This is possible using either PAM or the Opie modules. The module passes back a challenge which the user puts into a key generator along with their "pass phrase" and it gives them back 5 words which get sent as the password. As long as you do it correctly it will never repeat.
It requires http://inner.net/opie/ to be installed on the server. There are key gen clients for win95/98, *nix, mac.
The new mod_radius module provides RADIUS authentication and accounting support to ProFTPD.
Is it possible to check an offered email address in an anonymous login before allowing access. Simple answer, not a hope in hell, anonymous access is pretty much designed to be freely open without checks and restrictions other than those placed on upload/download from the site. The best that can be hoped for is decent logging and tracking of accesses, and the requesting IP.
If the operating system supports PAM (Pluggable Authentication Modules) proftpd will perform PAM authentication by default. However, this authentication is not "authoritative" by default, meaning that a PAM authentication failure will not necessary cause a login to fail. The use of PAM can be configured using the AuthPAM configuration directive; the "authoritativeness" of any PAM checks is controlled via the AuthPAMAuthoritative configuration directive.