ProFTPd Does Not Start Debian 10 Buster

Francewhoa commented 4 years ago

Steps to reproduce

Using Debian 10 Buster, install a fresh Virtualmin 6.08, using this install.sh
On Virtualmin Dashboard, under Servers Status, the ProFTPD FTP Server did not start. This is the challenge. We were able to reproduce this challenge on two different servers. Both fresh install. ProFTPD version 1.36. Clicking on the start button did not work. It never starts.
The expected result is that ProFTPD automatically starts on boot
To get more information about the cause of this challenge, using Terminal, run this command proftpd --configtest. It return this below. Where FQDN is the valid but masked Fully Qualify Domain Name.

Checking syntax of configuration file
2020-01-26 00:15:44,081 <FQDN> proftpd[4111]: processing configuration directory '/etc/proftpd/conf.d'
2020-01-26 00:15:44,082 <FQDN> proftpd[4111]: mod_dso/0.5: module 'mod_tls.c' already loaded
2020-01-26 00:15:44,084 <FQDN> proftpd[4111]: mod_tls/2.7: NoCertRequest TLSOption is deprecated
2020-01-26 00:15:44,085 proftpd[4111]: mod_dso/0.5: module 'mod_sftp.c' already loaded

Wrong passphrase for this key. Please try again.

Wrong passphrase for this key. Please try again.

Wrong passphrase for this key. Please try again.
2020-01-26 00:15:44,094 <FQDN> proftpd[4111] <FQDN> : mod_sftp/1.0.0: error reading passphrase for SFTPHostKey '/etc/proftpd/ssh_host_rsa_key': (unknown)
2020-01-26 00:15:44,094 <FQDN> proftpd[4111] <FQDN> : mod_sftp/1.0.0: unable to use key in SFTPHostKey '/etc/proftpd/ssh_host_rsa_key', exiting

Cause

In summary, the cause of this challenge is that Debian Buster 10 use the new OpenSSL key format. But ProFTPd version 1.36 use the older format. So they don't understand each others.

During Virtualmin installation this challenge is not detected. I guess because the challenge occurs only on ProFTPs start. Not on installation. So the users are not warned. Some users might jump to the false conclusion that Virtualmin "bugs". Details here about the cause of the challenge. This challenge seems to be more with ProFTPd than Virtualmin though.

Resolution 1

How about this suggested resolution 1? During Virtualmin installation, if the ProFTPd version is 1.36. Automatically run the following 3 command lines? Which resolve this challenge permanently.

ssh-keygen -m PEM -f /etc/proftpd/ssh_host_rsa_key -N '' -t rsa -b 2048
ssh-keygen -m PEM -f /etc/proftpd/ssh_host_dsa_key -N '' -t dsa -b 1024
ssh-keygen -m PEM -f /etc/proftpd/ssh_host_ecdsa_key -N '' -t ecdsa -b 521

Thanks to maxdevaine & unixsheikh for their contributions about those commands :)

Resolution 2

If the suggested resolution 1 above is somehow not realistic or not possible, how about, during Virtualmin installation, detect if the ProFTPd version is 1.36. Then continue the Virtualmin installation as usual. But after the installation is completed, add a warning message into the Virtualmin log display to users. Something like this or any other wording to your liking

ProFTPd version 1.36 was install. But will neither automatically start at boot nor manually start. This is due to a known challenge within ProFTPd version 1.36 itself. To resolve this challenge either find a resolution in this ticket at https://github.com/proftpd/proftpd/issues/793 or wait for ProFTPd version 1.37 to be released for Debian 10 Buster. ProFTPd have resolved this challenge with version 1.37 or more recent.

Resolution 3

How about this suggested resolution 3? Add some duct tape here and there. Duct tape always fixed anything ;) https://i.postimg.cc/kgmSgKD8/duct-tape-who-needs-a-spare-tire.jpg

iliajie commented 4 years ago

Hi,

Thank you very much for amazing feedback. :slightly_smiling_face:

However, I have a question - do you think it's right to workaround somebody else's bugs?

Francewhoa commented 4 years ago

Thank you very much for amazing feedback. slightly_smiling_face

You're welcome @rostovtsev :)

However, I have a question - do you think it's right to workaround somebody else's bugs?

No and yes:

No, because the bug is within ProFTPd. Not within Virtualmin. And as you know ProFTPd already have their own ticket about their own challenge at https://github.com/proftpd/proftpd/issues/793
Yes, because this Virtualmin ticket #139 is a suggestion for Virtualmin, not a suggestion for ProFTPd. And this challenge affect all Virtualmin users who use the default installation script install.sh with Debian Buster 10. As you know ProFTPd version 1.36 is the default FTP package installed with Virtualmin. And 1.36 includes this bug. Also Debian release last up to 4 years. This means roughly from July 2019 to July 2024. This means that those Virtualmin users will not be able to use ProFTPd for 4 years. Unless they somehow dig very deep to find a resolution. The suggested resolution 1 above would permanently resolve this challenge now within Virtualmin installation. Until the version 1.37 is added to Debian 10 Buster at some point in the future. As for the suggested resolution 2 above it would not resolve the challenge, but at minimum Virtualmin users would be notify and get some basic information about where to find a resolution. In other words, a smoother user experience.

With the resolution 1 there are potential unknown risks attached to making change to ProFTPd files during Virtualmin's installation. So my vote goes to the resolution 2. Which does not do any change to ProFTPd. But both warn and inform the users. So that they have a more pleasant experience with Virtualmin.

Beside the two to suggested resolution above, and the duct tape resolution, do you have any other suggestion to resolve this challenge?

At Ubertus we would be happy to contribute testing and documentation if needed

virtualmin / virtualmin-gpl