Random pass problem when creating new user accounts

wattie

Verified User
Joined
May 31, 2008
Messages
1,234
Location
Bulgaria
I am on FreeBSD 9.1, latest directadmin, custombuild 2.

I have a weird problem. When I create new account and choose random password - the DA login does not work. For example:

"Dear Customer,

Thank you for choosing our service to meet your web hosting needs.

Your account has been created with the following details:

Username: testing
Password: y1wCkr9Q
Domain: testing.com
"

y1wCkr9Q was generated by DA. I can login to FTP with it, but not in DA control panel.

When I type a password during the setup manually - both FTP and DA login work fine!
 
I think When DA wants save the generate password got problem, But that you said
When I type a password during the setup manually - both FTP and DA log in work fine!
makes my idea wrong!?!?!!!!!!!
Please share your solution with us.
Thanks in advance.
 
I was wrong sorry, I am misleaded by one reseller.

It does not work neither way. I cannot login with random or manual password - it does not work when creating a new account. I must go to the user, hit "New Random Password" and it will then reset the password and will work...

I shot in the dark that it could be something related to the non working password protect directories bug from the latest apache update...
 
Hello,

Did you check error logs? If not you'd better do that, as well as check the things while running directadmin in a debug mode.
 
Yes, I checked the error logs. When creating the user there is nothing new. When trying to login I get:

2013:03:18-21:55:23: Timeout from from *********** : last flagged: Request::readAndProcess(*skt, ***********, ***********)
2013:03:18-21:55:48: Timeout from from *********** : last flagged: Request::readAndProcess(*skt, ***********, ***********)

Where *********** is my IP
 
Then you might need to check the things while running directadmin in a debug mode
 
This is what happens when I hit "Create" on the account:
Code:
Cannot find first space after where GET or POST should be
Sockets::handshake - begin
Sockets::handshake - end
/CMD_ACCOUNT_USER
 0: Accept-Encoding: gzip, deflate
 1: Accept-Language: en-US,en;q=0.5
 2: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 3: Connection: keep-alive
 4: Content-Length: 168
 5: Content-Type: application/x-www-form-urlencoded
 6: Cookie: session=*************************************************
 7: Host: *************:2222
 8: Referer: [url]http://*************:2222/HTM_ACCOUNT_USER_CREATE[/url]
 9: User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Post string: action=create&username=testing&email=test%40teteteteteattae.com&passwd=uGXTSdk7&passwd2=uGXTSdk7&domain=testing.com&package=Solo&ip=91.215.219.129&notify=yes&add=Submit
Checking referer [url]http://*********:2222/HTM_ACCOUNT_USER_CREATE[/url] to ***********:2222
Referer check passed: **********=********* 2222/HTM_ACCOUN=2222
Command::doCommand(/CMD_ACCOUNT_USER)
User::create(password, 0) user=testing
User testing created successfully
stat(/home/testing) returned 0, just after user creation
stat info:
mode: 16877
uid:1313 (testing)
gid:1312 (testing)
size:512
atime:0
mtime:1363642524
ctime:1363642524
User::setQuota(200) user=testing
quota command: /usr/sbin/edquota -e /home:204800:225280:0:0 testing
Quotas set
Named::writeDB::error reading ./data/users/testing/user.conf to get package info.
File /etc/namedb/testing.com.db.temp appears ok to named-checkzone
Apache::get_cb_apache_ver == 2.4
IP::writeFile. Current list:
listType: 1

...
LIST WITH IP ADDRESSES
...
Command::doCommand(/CMD_ACCOUNT_USER) : finished
Command::run: finished /CMD_ACCOUNT_USER
Sockets::handshake - begin
Sockets::handshake - end
Cannot find first space after where GET or POST should be


What looks suspicious to me is:

1. "Cannot find first space after where GET or POST should be" - I get this after every click in DA.

2. "Named::writeDB::error reading ./data/users/testing/user.conf to get package info."

The file /usr/local/directadmin/data/users/testing/user.conf exists. Here is the content of it:

Code:
additional_bandwidth=0
aftp=OFF
bandwidth=50000
catchall=ON
cgi=ON
creator=admin
cron=OFF
date_created=Mon Mar 18 23:35:24 2013
dnscontrol=ON
docsroot=./data/skins/enhanced
domain=testing.com
domainptr=0
[email protected]
ftp=1
ip=***********
language=en
login_keys=OFF
mysql=1
name=testing
nemailf=50
nemailml=1
nemailr=50
nemails=50
ns1=ns1.**************
ns2=ns2.**************
nsubdomains=10
package=Solo
php=ON
quota=200
skin=enhanced
spam=ON
ssh=OFF
ssl=OFF
suspend_at_limit=ON
suspended=no
sysinfo=OFF
username=testing
usertype=user
vdomains=1
zoom=100


The /var/log/directadmin/2013-Mar-18.log have lines with:

18/03/2013:23:52:06 <MYIP> BAD REQUEST unknown
18/03/2013:23:52:06 <MYIP> BAD REQUEST unknown
 
Last edited:
User::create(password, 0) user=testing
User testing created successfully

Just a guess, you probably use a not supported password hashing algorithm.
Anyway more debugging is required, but you'd better have somebody to check it for you, if you don't know where and what to check.
 
The weird thing is that when I go to reset the password, it resets and I can login to DA with the user with no problems. Won't the reset password and the create new account algorithms be the same?

I will debug more when I have time. Thanks guys.
 
password and the create new account algorithms be the same?

Check then /etc/shadow and /etc/password files after a new account is created, and after you reset a password.
 
in /etc/passwd there is no difference before/after the reset. When I create the new account I get the following there:

testing:*:1321:1320:User &:/home/testing:/sbin/nologin
 
/etc/password does not contain hashes of passwords.
You should check /etc/shadow
I've mentioned both of them earlier.
 
Hello,

I believe it's an issue with FreeBSD 9 wanting to use SHA-512, but the DA binaries for FreeBSD (which are actually compiled on FreeBSD 8) do not like SHA-512.

For User creation, DA calls "pw" and passes the plaintext password via stdin, so pw does the encryption based on /etc/login.conf (I believe)
When the password is changed through DA, DA set it's with it's own crypt function, thus MD5 ($1$) is used.. which DA can read, thus it works.
If DA were compiled on FreeBSD 9, then SHA-512 would likely be fine but alas, it's not.. so this is what we've got.

Simple solution is to tell FreeBSD 9 to use MD5 ($1$) instead of SHA-512 ($6$)

Related, FreeBSD is at the bottom:
http://help.directadmin.com/item.php?id=248

set it to use md5, so that "pw" sets $1$ based passwords in the /etc/master.passwd file.

John
 
Sounds like the track to resolve the problem.

So far I tried the following two (with no luck):

1. I edited
Code:
/etc/login.conf
and changed
Code:
:passwd_format=md5:\

Should I restart some service to have that take effect? I didn't do anything, just tried and create new account and it did not work.

2. I reverted back the
Code:
login.conf
to
Code:
:passwd_format=sha512:\
, then I gone and edit
Code:
/usr/local/directadmin/conf/directadmin.conf
and added:

Code:
crypt_method=6

to it. Then restarted directadmin. Regarding the latest changelog that should make DA saving passwords in sha512. No luck here too. I create the new account and I cannot login, then I reset the password - I can.
 
Followup:

Now creating a new account in DA makes the following in /etc/master.passwd:

Code:
testuser:$6$pbmcveVLxRTyt7bcC$hrwuJ15GprN33s5dkm66WHzkMd26b0vagK9dACWdxqerV6kWrbCxfz1Latjq4rUlJOmgYJg1g0WpHLNAjZVLb.:1329:1328::0:0:User &:/home/testuser:/sbin/nologin

I can't login.

Then I go and reset the password. The /etc/master.passwd now contains:

Code:
testuser:$647FG6/7dR6U:1329:1328::0:0:User &:/home/testuser:/sbin/nologin

Now I can login... But the above does not look very good I guess. Where is the hash?

P.S. When crypt_method=1 in directadmin.conf, it resets the passwords like:

Code:
testuser:$1$vwl9jAwp$m4JBBgEM4jRWiQjgD/7k8/:1329:1328::0:0:User &:/home/testuser:/sbin/nologin
 
Last edited:
Hello,

As mentioned, the DA binaries for FreeBSD 9 do not support sha-512.
This means that this option will not work for you:
Code:
[COLOR=#333333]crypt_method=6[/COLOR]
Change it back to:
Code:
[COLOR=#333333]crypt_method=1[/COLOR]

The /etc/login.conf should be enough.. in theory.
You can test it by adding a User to the system with the "pw" command.. similar to this:
Code:
pw useradd -n testing -s /sbin/nologin -w no -h 0 -m
and when it just sits there, type in the plaintext password that you want, and use ctrl-d to close the pipe.
OR just create an account through DA.. probably easier.

Once it's created, check /etc/master.passwd to ensure you see the $1$ format for the crypt.

The goal here is to tell pw to create the passwords with MD5 ($1$)... and not sha-512 ($6$)

John
 
in /etc/passwd there is no difference before/after the reset. When I create the new account I get the following there:

testing:*:1321:1320:User &:/home/testing:/sbin/nologin


Sorry, I've missed the fact you are on FreeBSD, in this case you should check /etc/master.passwd
 
Back
Top