COMMAND DUMP – upgrading a standard proftpd install to TLS
upgrade a basic proftpd install to support FTPS with these commands
cd /etc/proftpd mkdir -p ssl openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem chmod 600 ssl/proftpd.*
Follow the prompts to put in your valid organization name
Then open the conf file #vi proftpd.conf and add the following (if the <IfModule mod_tls.c> directive already exist, replace the contents with the contenst below)
<IfModule mod_tls.c> TLSEngine on TLSLog /var/log/proftpd/tls.log #TLSProtocol TLSv1.2 TLSCipherSuite AES128+EECDH:AES128+EDH TLSOptions NoCertRequest AllowClientRenegotiations TLSRSACertificateFile /etc/proftpd/ssl/proftpd.cert.pem TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key.pem TLSVerifyClient off TLSRequired on RequireValidShell no </IfModule>
/etc/init.d/proftpd stop /etc/init.d/proftpd start
Your can test this by running the following command to make sure that you can connect using the certificate
openssl s_client -connect 127.0.0.1:21 -starttls ftp
proftpd stops running – once a week when logrotate.d runs
On Sunday mornings at 6:30AM I receive this log entry at the bottom of my /var/log/proftpd/proftpd.log file and proftpd stops running
2015-07-05 06:28:24,870 servera proftpd 127.0.1.1: ProFTPD killed (signal 15) 2015-07-05 06:28:24,871 servera proftpd 127.0.1.1: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN
The time (about 6:30AM) on sunday leads me to know from experience that is when the log files rotate if they are set to rotate weekly using logrotate.
So I go in search of the logrotate commands for proftpd with grep and find the following file
#grep proftpd -l /etc/logrotate.d/* /etc/logrotate.d/proftpd-basic
Inside of /etc/logrotate.d/proftpd-basic file, there is a command which restarts proftpd after the logs files are rotated
postrotate # reload could be not sufficient for all logs, a restart is safer invoke-rc.d proftpd restart 2>/dev/null >/dev/null || true
When I run this at the CLI, I find that every other time I run the command, proftpd does not start! This seems to me to be a timing issue, so I simply but a sleep command between the stop and start commands in the restart script
/etc/init.d/proftpd force-reload|restart) if [ "x$RUN" = "xyes" ] ; then signal stop 1 sleep 1 #ADDED BY Michael Blood to avoid a timing issue that would not allow the start if the stop did not complete. start
This appears to fix the problem perfectly.
Proftpd: FTP Permission denied – Even after confirming correct AuthUserFile user and path permissions
On A VPS – even though we hav the correct user setup in the proftpd.conf file
User www-data Group www-data
and I have virtual users setup in proftpd.conf
and the user I am logging in setup with a special home page in my ftpd.passwd
and the permssions on my directory were correct
#cd /data/webs/mydomain.com #ls drwxr-xr-x 2 www-data www-data 4096 Jun 27 14:04 htdocs
So i started up proftpd in my console
and tried to save an temp.txt file via ftp and I got alot of log files, but this is the one that tipped me to the problem
2015-07-01 06:50:27,117 myserver proftpd 127.0.1.1 (x.x.x.x[x.x.x.x]): in dir_check_full(): path = '/temp.txt', fullpath = '/var/www/temp.txt'.
So it appears that proftpd, while reading the ftpd.passwd to find the username and password, was not reading the home page.
When I checked the permissions on /var/www it turns out that directory was owned by root, so I changed it (the directory is empty unused, i just wanted to confirm whether
#cd /var #ls drwxr-xr-x 2 root root 4096 Jun 27 14:04 www #chown www-data.www-data /var/www
Then when I tried to save a junk.txt file, it was saved correctly
2015-07-01 07:44:33,024 myserver proftpd 127.0.1.1 (x.x.x.x[x.x.x.x]): Transfer completed: 0 bytes in 0.03 seconds
This confirms it, the home directory in the ftpd.passwd file is not being used correctly, so i have to find out why note. So I started to dig back through the output and found this line
unable to chdir to /data/webs/mydomain.com/htdocs (No such file or directory), defaulting to chroot directory /var/www
Ultimately I found that the DefaultRoot variable was not supposed to be overridden by the /home directory, it turns out that the DefaultRoot works WITH the /home directory in the ftpd.passwd file to determine where to place the user. So the fix for this issue was to simply replace the DefaultRoot /var/www with
This tells proftpd to use what ever home directory is in the ftpd.passwd file.