trouble changing password on FTP account

[mbrand]

I have come across a strange situation. I want to change the password of an FTP account. The standard procedure on the FTP Setup page works fine if I then attempt to log in as just “user”. That is, the old password does not work and the new password does work.

The problem is that if I attempt to login by FTP as “[email protected]” I can still do so with the old password.

Attempting to clear any caches that might exist, I then restarted proftpd (still able to login with old password), restarted httpd (same problem), then restarted the whole VPS (same problem).

I then completely deleted the FTP account of [email protected]. I can still log in by FTP if I use the full login name of [email protected] and the old password. The new password does not work with the long login. That is, on the FTP Setup page at the User Panel level, the list of login accounts does not include “user”, but yet I can login with [email protected] and the old password.

Any ideas on what is going on and how to disable login by the long login name and old password?

Thanks,
Mike

 

[DirectAdmin Support]

Hello,

A bit of information. Is or was this account placed on an owned IP?... such that it has it's own ftp password file, and when you access the IP from a browser, you see the webpage, and not a "this is a shared IP" page?

What does the value in the "Login" column on the ftp page show? If anything at all.

Here is some info on how owned IP accounts are setup with ftp, so you can check a few files:
http://help.directadmin.com/item.php?id=122

Check to see what password file the account is in:
/etc/proftpd.passwd
or
/usr/local/directadmin/data/users/username/ftp.passwd

Also, if this is the system account (same as DA login) you're referring to, try setting:
AuthPAM off
in the /etc/proftpd.conf, then restart proftpd. If proftpd doesn't start up, take out that line, it's not a PAM problem. (it shouldn't be using pam)

John

 

[mbrand]

Hi John,

Thanks for your help. Based on what you told me, I was able to solve the immediate problem. However, there seems to be an issue with DA (see below).

Is or was this account placed on an owned IP?

Yes, the account has a dedicated IP (so that it can have an https cert).

What does the value in the "Login" column on the ftp page show? If anything at all.

If you mean the “Ftp Setup” page that has a table with headers of Account, Server Path, Password, Select, then there is no entry for the ‘user’ in question under the Account column (and no record at all for that ‘user’).

/usr/local/directadmin/data/users/username/ftp.passwd

I found the password file at the above location and was able to replicate the problem.

There was an entry for the older login name in the long form of [email protected]. I deleted that line from ftp.passwd and was then not able to login using that long login. That is, the problem was solved.

Then I created a new user [email protected]. I tested FTP access with the short login of shop. The ftp.passwd file includes two entries that start with shop and [email protected]. Then I deleted that account from DA at the “Ftp Setup” UI. The login shop could not connect by FTP, but the long login of [email protected] could log in. The ftp.passwd file now includes just one entry: the long login of [email protected].

That is, deleting an FTP account is only deleting the short login entry and not the long login entry from ftp.passwd

Also, if this is the system account (same as DA login) you're referring to,

That is not the case here. That is, DA login is different from owner of the account.

Thanks,
Mike

 

[DirectAdmin Support]

check:
/usr/local/directadmin/data/users/username/domains/domain.com.ftp

There should be an option:

defaultdomain=yes
or
defaultdomain=no

if the domain is the only domain on the account, then it should be showing defaultdomain=yes, and account login format should just be "shop" without the @domain.com at the end. If it's a secondary domain on the account, then defaultdomain=no, and it will have the form [email protected]

John

 

[mbrand]

if the domain is the only domain on the account, then it should be showing defaultdomain=yes, and account login format should just be "shop" without the @domain.com at the end. If it's a secondary domain on the account, then defaultdomain=no, and it will have the form [email protected]

It is the only domain on the account, and defaultdomain=yes in domain.com.ftp, but both short and long login forms are present in ftp.passwd. Here they are, with the encrypted password and domain name X'd and Y'd out:

shop:xxxxx:505:505:domain:/home/outlet/domains/yyyyy.com:/bin/false
shop@yyyyyyy .com:xxxxx:505:505:domain:/home/outlet/domains/yyyyyy.com:/bin/false

Am I understanding correctly that the above is not the expected setup? If the code to delete an FTP account is expecting just one login form, then the fact that there are two login forms could explain why one is not being deleted. Just a thought.

Thanks,
Mike

 

[DirectAdmin Support]

oh, there are 2. I didn't catch that. That would be it There should only be one. Delete the ones that don't show up in DA.

John

 

[mbrand]

oh, there are 2. I didn't catch that. That would be it There should only be one. Delete the ones that don't show up in DA.

John, thanks for your help as I now know how to manually dissable FTP access for the long login. However, the fact that the long login is not deleted when an FTP account is deleted seems like a security risk to me. The presumption would be that once the FTP account is deleted, access through that FTP login would be disabled. But that is not currently the case unless the admin manually modifies the domain.com.ftp file to remove that long login. Could you add this issue to the project list for DA?

Thanks,
Mike