COMMAND DUMP – upgrading a standard proftpd install to TLS

Posted on January 11, 2016

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>

Restart proftpd

/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

Posted on July 7, 2015

proftpd

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[31258] 127.0.1.1: ProFTPD killed (signal 15)
2015-07-05 06:28:24,871 servera proftpd[31258] 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

Posted on July 1, 2015

proftpd

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

AuthUserFile /etc/proftpd/ftpd.passwd

and the user I am logging in setup with a special home page in my ftpd.passwd

myusernamexxxx:$MYENCRYPTEDPASSXXXX:33:33::/data/webs/mydomain.com/htdocs:/bin/bash

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

proftpd -nd10

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[11396] 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[20581] 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

DefaultRoot ~

This tells proftpd to use what ever home directory is in the ftpd.passwd file.