SOLVED [CPANEL-25776] phpMyAdmin login issue since WHM 80 update

[morrow95]

Logging into phpMyAdmin gives the following error since WHM updated to v 80 the other day for me. Picture attached.

Login without a password is forbidden by configuration (see AllowNoPassword)

mysqli_connect(): (28000/1045): Access denied for user 'root'@'192.168.10.3' (using password: YES)

Undefined index: auth_type​

I am using a username/password, as I always have, so I find it strange this error is showing. Something clearly was changed since the update to WHM 80 as I have made no changes recently nor have there ever been problems with it prior (couple years now).

 

[cPanelLauren]

Hi @morrow95

Can you give me the output of the following:

/scripts/restartsrv_mysql --status

grep sock /etc/my.cnf

 

[morrow95]

Hi @morrow95

Can you give me the output of the following:

/scripts/restartsrv_mysql --status

grep sock /etc/my.cnf

We use a remote database so the service is disabled.

With that said, the my.cnf means nothing either, but here it is in full anyways :

[mysqld]
default-storage-engine=MyISAM
innodb_file_per_table=1
max_allowed_packet=268435456
open_files_limit=10000


As for the current config, we created a superuser for the remote db and created a profile for it in Manage MySQL® Profiles in WHM. Here is our /root/my.cnf (edited for sensitive info) on the server with WHM :

[client]
#db.example.com whm_remote
user=whm_remote
password="somepassword"
host=192.168.10.2
port=3306
[mysqld]

whm_remote being the same superuser setup in Manage MySQL® Profiles to access the remote db. This setup has worked fine for 4-5 years now. It was only the other day I noticed the error with phpMyAdmin and it just happened that WHM v80 was updated before that. I had accessed phpMyAdmin no less than a week or two ago as normal with no issues.

 

[cPanelLauren]

None of that is actually what I was looking for unfortunately, I've seen a couple cases where the sock file was being referenced in a new location causing this issue but there's not a way to know if that's the case from this. Can you please open a ticket using the link in my signature? Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved.


Thanks!

 

[morrow95]

None of that is actually what I was looking for unfortunately, I've seen a couple cases where the sock file was being referenced in a new location causing this issue but there's not a way to know if that's the case from this. Can you please open a ticket using the link in my signature? Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved.


Thanks!

This is all I could provide for what you asked since none of it applies to this situation. As I mentioned we use a remote database. The user setup in WHM to access it is valid of course and there are no issues with our database either. This would also rule out your sock related case. This seems to be related to WHM and the recent update (or perhaps phpMyAdmin was updated?) - not with our database since it is remote and is working perfectly fine.

I guess I'll file a ticket.

 

[morrow95]

ticket 12504247

 

[cPanelLauren]

This is all I could provide for what you asked since none of it applies to this situation. As I mentioned we use a remote database. The user setup in WHM to access it is valid of course and there are no issues with our database either. This would also rule out your sock related case. This seems to be related to WHM and the recent update (or perhaps phpMyAdmin was updated?) - not with our database since it is remote and is working perfectly fine.

Right, unfortunately, it doesn't apply, being able to see what's happening on the system will be helpful in resolving the issue I believe.

I just checked in on that ticket and it appears one of our Level III analysts is working on this and attempting to reproduce the error on a test environment and he's looking for more information from you on the remote MySQL instance.

 

[cPanelLauren]

Hi @morrow95

It looks like one of our analysts found that this issue was related to an open case CPANEL-25776 which is identified as being fixed in v82 of cPanel/WHM
It looks like there's a request to have this patched to v80 as well and I'll update here as I have more information.


Thanks!

 

[morrow95]

For those curious, they were able to replicate this problem. It worked fine on v78 and did not on v80. phpMyAdmin is forcing login to the same username you are logged into WHM as. In our case this posed a problem as the username we login to WHM as does not have access to our remote database. Seems like somewhere between 78 - 80 a change was made where it no longer uses the information provided in either /root/my.cnf (user/pass to the remote db is listed) or the access setup in Manage MySQL® Profiles of WHM (same user/pass). The latter sounds more likely as previously we would log into phpMyAdmin with the same user/pass as WHM, but would be logged in as our superuser created (whm_remote in our case) which would be correct as the profile setup in Manage MySQL® Profiles is meant to give WHM access/login credentials when needed.

 

[cPanelMichael]

Hello,

To update, here's the entry in the cPanel & WHM version 82 Change Log noting the fix for this issue:

Fixed case CPANEL-25776: Use authentication in .my.cnf when accessing WHM > phpMyAdmin.

You can see which versions are published to each Release Tier on the link below:

Latest cPanel & WHM Builds

Thank you.

 

[morrow95]

Hello,

To update, here's the entry in the cPanel & WHM version 82 Change Log noting the fix for this issue:

Fixed case CPANEL-25776: Use authentication in .my.cnf when accessing WHM > phpMyAdmin.

You can see which versions are published to each Release Tier on the link below:

Latest cPanel & WHM Builds

Thank you.

Do you know if there will be a patch for v80 or not?

 

[cPanelMichael]

Do you know if there will be a patch for v80 or not?

Hi @morrow95,

A request to backport this fix into cPanel & WHM version 80 is open. We'll continue to monitor the case and report new information on the status of the backport request as it becomes available.

Thank you.

 

[Erik Knepfler]

It's baaack.

This just started happening on one of my servers. Possibly as recently as today or yesterday.

Currently on cPanel v92.0.6 and some updates occurred recently.

A client told me their phpMyAdmin was reporting "Login without a password is forbidden by configuration (see AllowNoPassword)"
I logged into their client cPanel and confirmed the error. Login fails even when entering valid credentials into phpMyAdmin manually (I know they're valid because credentials are same as wp-config for WP site that loads fine, and I can even connect via the command line and type show_databases.)

If I access the client's cPanel from WHM as root, it works fine. Error only occurs when logging in as the client.

Wasn't this fixed way back in in v82? I'm at v92!

 

[cPRex]

@Erik Knepfler - I just checked a 92.0.6 machine by logging into cPanel directly as the user, and I was able to access PHPMyAdmin normally on my end. I also don't see any similar reports when I checked our ticket system, so it's possible this is just an isolated issue with your system.

It may be best to submit a ticket to have our team investigate. If you submit a ticket, please post the number here so I can follow along and keep this thread updated with our findings.

 

[neverforget98]

I've been seeing the same issue as Erik since the most recent update. I've attempted a number of resolutions to try to fix this, nothing is working. I've tried to:
-reset the users password
-check for and remove /home/$username/.my.cnf (wasn't in either user)
-reset root mysql password
-reboot server

I can reproduce this on every user I've tested on my server on the recent update. I've opened a ticket #94042682 - I hope this bug gets resolved soon.

Thank you,
Brandin.

 

[cPRex]

@neverforget98 - it looks like our team was able to see the issue with your system, specifically that your server was using MariaDB 10.4. If you're still seeing issues just let me know!

 

[neverforget98]

That is true, the issue is related to MariaDB 10.4 and CloudLinux's lack of ability to display a warning before allowing this upgrade which is problematic and precisely one of the reasons I avoided using it for so long - their lack of accountability when it came to ensuring users were still meeting software guidelines when replacing built in features. I'm now attempting to migrate the databases and users to a 10.3 server and then back after an uninstall and reinstall - currently testing in a staging environment and will report back with its results.

 

[cPRex]

Thanks for the update - I know there's a CloudLinux case open to provide a warning during that change, but it hasn't been implemented on their end just yet.

 

[neverforget98]

While this process was a lot to handle and resulted in 4 hours of work, I was able to rollback to MariaDB 10.3 from MariaDB 10.4 without data loss doing the following.

BEFORE YOU CONSIDER DOING THIS, THIS IS VERY VERY VERY RISKY. But for the most part you'll be able to work you way through this using these steps. Note that something might throw you for a loop, so be prepared to respond to whatever breaks down during the process. I had to uninstall MariaDB 3 times to get it to work again.

1. Setup a temporary cPanel server with MariaDB 10.3
2. Use the transfer tool to transfer the plans and server settings to avoid any conflictions
3. Full backup of the primary server, twice, to ensure any data loss could be reverted
4. Disable HTTP(s) access requests to the primary server via firewall
5. Transfer the accounts to the temporary server using the Transfer Tool -> BE SURE TO DISABLE LIVE TRANSFER TO AVOID DATA LOSS
6. Verified in phpMyAdmin on the temporary server that no tables were corrupt by spot-checking databases
7. Terminated accounts on the primary server
8. Turned off MySQL

service mysql stop

9. Removed MySQL Governor

/usr/share/lve/dbgovernor/mysqlgovernor.py --delete` (NOTE: THIS WILL FAIL since there is no 10.4 for cPanel)
10. Install MariaDB 10.3 [CODE]yum install MariaDB-client MariaDB-common MariaDB-compat MariaDB-devel MariaDB-server MariaDB-shared

11. Remove MySQL Governor on MariaDB 10.3

/usr/share/lve/dbgovernor/mysqlgovernor.py --delete

12. Remove MariaDB 10.3

yum remove MariaDB-client MariaDB-common MariaDB-compat MariaDB-devel MariaDB-server MariaDB-shared

13. Remove the remnants of MariaDB 10.3 (or its likely to fail starting up)

rm -rf /var/lib/mysql

14. Make sure the lock is removed

rm /var/lock/subsys/mysql

15. Install MariaDB 10.3

yum install MariaDB-client MariaDB-common MariaDB-compat MariaDB-devel MariaDB-server MariaDB-shared

16. Run the SecureMySQL Script

/usr/local/cpanel/scripts/securemysql

17. Verify MariaDB started (check phpMyAdmin)
18. Probably should reboot your server
19. Transfer the accounts back to the primary server
20. Enable HTTP(s) access

Good luck if you dare...