I recently upgraded my server to use the latest Proftpd - first time in a year probably I got it up to date (don't ask how painful that was. I promise to be better). But this newest version :
$ pacman -Q proftpd proftpd 1:1.3.4b-3
seems to be ignoring the RequireValidShell setting in the conf file:
# This is a basic ProFTPD configuration file (rename it to # 'proftpd.conf' for actual use. It establishes a single server # and a single anonymous login. It assumes that you have a user/group # "nobody" and "ftp" for normal operation and anon. ServerName "Amazingdev.com server" ServerType standalone DefaultServer on # Port 21 is the standard FTP port. Port 21 # Don't use IPv6 support by default. UseIPv6 off # Umask 022 is a good standard umask to prevent new dirs and files # from being group and world writable. Umask 022 RequireValidShell off # To prevent DoS attacks, set the maximum number of child processes # to 30. If you need to allow more than 30 concurrent connections # at once, simply increase this value. Note that this ONLY works # in standalone mode, in inetd mode you should use an inetd server # that allows you to limit maximum number of processes per service # (such as xinetd). MaxInstances 30 # Set the user and group under which the server will run. User nobody Group nobody # To cause every FTP user to be "jailed" (chrooted) into their home # directory, uncomment this line. DefaultRoot ~ # Normally, we want files to be overwriteable. AllowOverwrite on # Bar use of SITE CHMOD by default <Limit SITE_CHMOD> DenyAll </Limit>
because I do, in fact, need to give my users a valid shell or else they get the dreaded 530 User Access Denied error. I just to give them '/sbin/nologin' for a shell, but how I have had to switch it to /bin/sh.
I Googled but didn't see anyone else complaining about it. Any idea what else I may be doing incorrectly?
Last edited by jdarnold (2012-10-09 03:28:26)
Never mind - user error. I didn't notice that after I started proftpd, I started ftpd. So all the changes in the world to proftpd.conf weren't going to affect the ftp server that was actually running