A few days ago I set out to do a 5 minute task that turned into hours of head scratching, and some learning. This is the story of how I spent hours trying to set up an FTP account.
The task was really simple: set up a new ftp account on my server so that a client can upload files that will be processed by the system we are building. I thought I’d be done in 5 minutes. Just log in to the DirectAdmin (DA) panel, create a new account, and share the credentials. However, as it always happens, things did not go as planned. After setting up the new account I was unable to log in.
In the past, I had noticed that the system monitor in DA showed the ProFTPD service as stopped, but since I don’t really use FTP, and the existing FTP accounts worked well, I didn’t think much about it. But now it was time to pay a little more attention to that.
I went ahead and tried to restart the proftpd service
service proftpd restart
What was my surprise when the command came back saying that the service was not recognized. What is running the FTP then? Time to find out
service --status-all | grep "ftp"
I quickly learned that my server was in fact running Pure-FTPd, so I searched for its documentation. I learned about virtual users, which was my first nice piece of knowledge that I got this time, specially because in the past I had wondered how the FTP users worked in the server because there were no accounts that matched the FTP users. Back when I had a localhost running FTP for development I had to create system accounts for every FTP user I wanted to add, but not on this server.
Watching the log files I learned that 1) Mac’s finder will strip anything after, and including the @ symbol if it appears in the username, which was the case with my username. and 2) that once I started using an FTP client that did not have that behavior the server would just not let me in and all it said was that the authentication was wrong. This got me running in circles changing the password and typing it as carefully as I could just to make sure it was OK. But no luck.
Reading some stackoverflow answers I started experimenting with the pure-pw command, and it kept complaining that the /etc/pureftpd.passwd file was not found. There was however a /etc/proftpd.passwd file. I decided to re-create the Pure-FTPd database using that file.
pure-pw mkdb -f /etc/proftpd.passwd
After doing this I could finally log in via FTP. It took me about two hours to get to this point, and while I could just call it a day, send the credentials, and go home, something kept bugging me. Why would DA not be able to properly manage my FTP users. Also, at this point I had noticed that while I had changed the password for my FTP account not long ago after the first time I had issues with FTP, the password hadn’t actually been set. What was going on?
So, let me open this parenthesis to explained what happened before, and how this problem has been there for a while now without me noticing. A couple of weeks ago I was looking for some files that I thought may be on my server (they weren’t). I wanted to FTP into the server to see if the files were there. I could not FTP. Since it had been a long time since I had used the FTP account, I decided to just go into DA and reset the password, but no matter what I set the password to, I could not log in. Finally, I decided to contact support, and ask them to look into the problem. I changed the admin DA password to a temporary password, and sent it to them. They looked into the issue, and after some back and forth, they came back saying that the problem was fixed. When I asked what had happened, they just said there were inconsistencies with the login system. I went back into DA and changed the password again, but since I had already tested that the FTP account worked before changing the password, I didn’t bother to test again after changing the password. Yesterday I realized that password change hadn’t taken effect.
I now know that support simply set the password to what I told them the password was, which is why the account worked after they looked into the issue. However, they didn’t realize that changing the password in DA did not have any actual effect on the account.
At this point it became clear that DA thought it was dealing with ProFTPd, as evidenced by the system monitor saying ProFTPD was stopped. After reading documentation and experimenting I finally set the correct ftp setting on DA.
I should mention that I spent quite some time digging on the custom build script and learning a bit about its internals. But since I didn’t want to re-install the FTP service, I ended up using the directadmin binary to set the ftp configuration. You can also do this manually by editing the directadmin configuration file. Just like you can manage your ftp accounts by manually editting the passwd files.
directadmin set pureftpd 1 restart
After doing this, things now work correctly, except that DA insists on adding @domain.com to the FTP user names. That is something I was not able to get rid of from the DA panel, but I can easily edit the passwd file, change the name there, and rebuild the db. I just need to remember not to modify the FTP accounts from DA because that will bring the old username format back.
A couple of weeks ago I also had to set up an SFTP account, but that is a topic for another post. However, I’m mention it here because I want you to stay tuned for that article because using plain FTP is not recommended. Unfortunately, the client had issues on implementing a service that used that SFTP account, and requested a simple, plain, old FTP account. The data we are dealing with is not sensitive at all, and it is in fact information that we WANT to have available to the general public. We just want to present it in a nicer way, which is why we process it first. However, I do not recommend using plain FTP if you can avoid it. There are better options, such as FTPS and SFTP.
Buzu's Oficial Blog 