ftp password storage format

W

Willis

Verified User
Joined
Dec 31, 2005
Messages
38
FTP user restore with custom paths

I recently moved a site DA->DA using the built-in site backup function, however, I have found that some ftp accounts did not transfer over.

Upon further inspection, I see that the accounts that did not transfer over used a different encryption for passwords in ftp.passwd (old style was alpha-numeric, new style is alpha-numeric-special)

The accounts still work on the old site, but will not transfer to the new one, what can be done to solve this short of resetting passwords?

[edit]
We have since found that the subject at hand has nothing to do with ftp password encryption, but rather the importing of users with 'custom' paths while importing to a DirectAdmin account of a different name.

DirectAdmin support is now looking into making the import more aware of custom ftp paths
[/edit]
 
Last edited:
I should also note that when using the restore option on the new site, it gives no errors about bad passwords, the accounts just don't transfer.

I've tried manually copying the ftp.passwd file, but it never seems to take, even with a directadmin reload or restart
 
Do both systems run the same OS distribution?

I've brought this thread to the attention of DA support.

Jeff
 
Hello,

I'm not sure if this is related or not, depends what you mean by "special". Several releases ago (maybe 6 months)we changed the format of the the crypt command usage. We still use crypt, but start off the crypt key with $1$ so that the password uses the newer crypt format (md5 is the new one, DES is the old one).

For decrypting, it doesn't matter which format is there, the crypt command will know which encryption was used (based on the first few 'key' characters) and should still decrypt correctly.

So try resetting your DA/ftp account password to see if that changes anything.

As for the "dont transfer" issue.. (the accounts actually aren't there) it might be a limit blocking the restore? I'm not sure. Check the User accounts ftp limit to make sure they can be restored.

John
 
Original site is running RedHat 9
New site is CentOS 4.2

Both are running DirectAdmin 1.26.1
Original site is running ProFTPd 1.2.9
New site is running ProFTPd 1.2.10

Since I have root on the new site, I copied the contents of the ftp.passwd file, modified it manually to the proftpd password file, and pasted it into /etc/proftpd.passwd and the passwords work fine, so it appears to be a problem in the backup parser.

The accounts with the older encryption would transfer via the restore function, those with newer encryption would now, though the password encryptions were valid to ProFTPd.
 
Hello,

Can you explain how exactly the encrypted data was showing up? Perhaps an example. Maybe send us an email with the output that was invalid, and the password that it was representing. If possible, also extract the user.tar.gz file, go into ./backup/domain.com/ftp.passwd and send us the line for that user as well so we can see if there is a problem.

John
 
You must log in or register to reply here.
Back
Top