[SOLVED]Proftpd Login not possible

[bluetaurus]

Hi,

i have a new server with CentOS release 5.4 (Final) and the ispCP 1.0.2 Omega release. Panel, Mails etc. working fine so far. Even the SSL hosts had been migrated in minutes. Moved my customers from and old debian server with syscp and enjoyed the new features and the good performance of the new host... and then i tried to add some ftp users but checking them resulted in several problems.

Installed Versions:

Code:

proftpd                                  x86_64                            1.3.2a-5.el5
proftpd-mysql                            x86_64                            1.3.2a-5.el5

I had to disable the "DisplayFirstChdir" setting because of:
- Fatal: unknown configuration directive 'DisplayFirstChdir' on line 54 of '/etc/proftpd.conf'

The rest of the config file is the proftpd ispcp standard.

Server is starting and listening. Users are found in the db but password is not accepted.

Here's the output of proftp -nd10

Code:

srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - connected - local  : 78.46.110.5:21
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - connected - remote : 93.104.41.207:61749
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - FTP session opened.
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'USER mgoetz@bluetaurus.de' to mod_tls
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'USER mgoetz@bluetaurus.de' to mod_core
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'USER mgoetz@bluetaurus.de' to mod_core
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'USER mgoetz@bluetaurus.de' to mod_delay
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'USER mgoetz@bluetaurus.de' to mod_auth
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching CMD command 'USER mgoetz@bluetaurus.de' to mod_auth
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - retrieved group IDs: 2002, 2002
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - retrieved group names: bluetaurus.de, bluetaurus.de
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching POST_CMD command 'USER mgoetz@bluetaurus.de' to mod_sql
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching POST_CMD command 'USER mgoetz@bluetaurus.de' to mod_delay
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching LOG_CMD command 'USER mgoetz@bluetaurus.de' to mod_sql
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching LOG_CMD command 'USER mgoetz@bluetaurus.de' to mod_log
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_tls
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_sql
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - retrieved group IDs: 2002, 2002
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - retrieved group names: bluetaurus.de, bluetaurus.de
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_vroot
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_delay
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_auth
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching CMD command 'PASS (hidden)' to mod_auth
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - retrieved UID 2002 for user 'mgoetz@bluetaurus.de'
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - ROOT PRIVS at mod_auth_pam.c:306
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - RELINQUISH PRIVS at mod_auth_pam.c:476
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - USER mgoetz@bluetaurus.de (Login failed): Incorrect password.
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching POST_CMD_ERR command 'PASS (hidden)' to mod_sql
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching POST_CMD_ERR command 'PASS (hidden)' to mod_vroot
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching POST_CMD_ERR command 'PASS (hidden)' to mod_delay
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching LOG_CMD_ERR command 'PASS (hidden)' to mod_sql
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching LOG_CMD_ERR command 'PASS (hidden)' to mod_log
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching LOG_CMD_ERR command 'PASS (hidden)' to mod_auth
srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - FTP session closed.

Anyone some hints for me?

Thanks,

Matt

[bluetaurus]

some further infos:

Updated to

Quote:ProFTPD 1.3.2a (maint) (built Mon Sep 7 10:29:05 EDT 2009) standalone mode STARTUP

and the mysql module via a manual installed rpm.

Same problem.

I checked the database user and password of the config file using the mysql command line. Authentication is working and i can read from the database tables.

I think it's not the typical problem of access the database, because the correct group and user ids are fetched!

Anyone some suggestions?

Thanks

Matt

[BeNe]

Do you have any special chars in your Password ?

Greez BeNe

[bluetaurus]

Hello BeNe,

no - i tried different user and pass combinations, even unsafe words without numbers or special chars. Problem occurs with every user.

Matt

---

another log part from /var/log/secure:

Nov 16 20:23:37 srv01 proftpd: pam_succeed_if(proftpd:auth): error retrieving information about user test@domainxy.de
Nov 16 20:23:40 srv01 proftpd[15345]: srv01.bluetaurus.de (93.104.167.23[93.104.167.23]) - USER test@domainxy.de (Login failed): Incorrect password.
Nov 16 20:23:42 srv01 proftpd[15345]: srv01.bluetaurus.de (93.104.167.23[93.104.167.23]) - FTP session closed.

Is this perhaps a problem with the /etc/pam.d/proftpd settings? Perhaps somebody could paste a working file...

Thanks!

[anarking]

Maybe proftpd is not actually using the sql module yet? Version 1.02 needs some modifying with proftpd configurations... in my install experience... (though most fixed with the new dailys) though mine was with ubuntu, perhaps the configs are the same needed with CentOS...

in /etc/proftpd/proftpd.conf

Uncomment:
#Include /etc/proftpd/modules.conf
to
Include /etc/proftpd/modules.conf

save and close that.

Now modify /etc/proftpd/modules.conf
Uncomment the following two lines:

LoadModule mod_sql.c
LoadModule mod_sql_mysql.c

then restart the proftpd daemon with new config.

just a guess. good luck!

[BeNe]

Code:

srv01.bluetaurus.de (93.104.41.207[93.104.41.207]) - dispatching POST_CMD_ERR command 'PASS (hidden)' to mod_sql

Mod_SQL is used, but i´m not sure if CentOS also need the "mod_sql_mysql.c".

Greez BeNe

[bluetaurus]

Problem solved!
Again my setup:

Centos 5.4 Final
with Proftpd 1.3.2a from epel repository

Code:

proftpd                                  x86_64                            1.3.2a-5.el5
proftpd-mysql                            x86_64                            1.3.2a-5.el5

These changes are necessary to get Proftpd working:

In proftpd.conf change:

1. Deprecated "DisplayFirstChdir"

DisplayFirstChdir message

to

DisplayChdir message


2. Change Authorder

AuthOrder mod_sql.c mod_auth_pam.c* mod_auth_unix.c

to

AuthOrder mod_sql.c mod_auth_unix.c


Thanks for all your help, guys!

Greets,

Matt

[hvm_pt]

Hi there!

This is just a post for further reference to anyone that have/had the similar issue I had with ProFTP not accepting the *correct* password, and the replies found in the above posts were of no help at all. :-/

I've just started to use ispCP version 1.0.2 and I also add some issues with it, since I'm using PHP 5.3.
There are small but significant changes in this PHP version that trigger some issues with this version of ispCP, that was programmed for a previous PHP version.
Apart from E_DEPRECATED warnings all over the place and the lack of the new mandatory (?) date_default_timezone_set() function that got me hacking the code a bit, the most disturbing issue I had was with FTP not accepting the username's password.

After several days of hair pulling troubleshooting :-) I've found that, if I changed the password directly through mysql queries, I was able to login.
So, doing this:

Code:

$ mysql ispcp -u root -p
Enter password: ******
(...)
mysql> update ftp_users set passwd=encrypt('password1234') where userid='user1@domain1.com';

I was able to login in FTP with the specified password!
But not if I changed the password from ispCP interface.
So it was a crypt issue somewhere!

Then, after an hard search, I found out about this two trouble tickets.

http://isp-control.net/ispcp/ticket/1876
http://isp-control.net/ispcp/ticket/1897

The solution is:

edit the file ispcp/gui/include/calc-functions.php and in the function

PHP Code:

function crypt_user_pass_with_salt($data) {

    $res = crypt($data, generate_rand_salt()); return $res;

} 


correct the "crypt" line like below:

PHP Code:

function crypt_user_pass_with_salt($data) {

    $res = crypt($data); return $res;

} 


This one was a nasty one! Very hard to find what was happening...so here's my contribution.

Cheers,
Hugo

P.S.: First post! :-)

[motokochan]

Salting passwords is a good thing, don't disable a security-enhancement!

The problem actually appears to originate in the generate_rand_salt function. Basically, blowfish and md5 are preferred in that order, and proftpd only accepts traditional UNIX crypt (DES) passwords. I haven't tested with htpassword generation, but if you follow the instructions I posted in this post, the salt generator will generate salt for DES/crypt password hashes.