• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Can't access from external IP via "admin" and password from /etc/psa/.psa.shadow with allowed external access [checkbox] - why?

jmar83

Regular Pleskian
Server operating system version
Debian 10.12
Plesk version and microupdate number
18.0.45
Can't access MariaDB 10.3.x on Plesk 18.0.45 on Debian 10.12 with "admin" - which is "root" user for MariaDB or MySQL in Plesk at least as i know!?

And remote connections are fully allowed on global MariaDB settings.

Screenshots HERE:

1.) Plesk global (Database independent) settings on "Tools & Settings" link:

2.jpg

2.) HeidiSQL connection settings:

1.jpg


3.) Feedback when i try to connect:
3.jpg


...i tried to get the MariaDB root / admin from cat /etc/psa/.psa.shadow - as described HERE: Resolved - how to get the plesk obsidian mysql / mariadb (?) root-replacement user "admin" password?

But the password doesnt seem to be problem, more the IP whitelist. BUT WHY WTF if the checkbox for external access is activated on global settings config site for "admin" user!?

Bug??


Thank you very very much for your feedback(s). :)
 
OK - for troubleshooting purposes: When i use a SSH tunnel over Debian "root" user in HeidiSQL, publicserver.com:22 for SSH, localhost:3306 for MariaDB, it works.

So clearly a permission / IP whitelist problem. But i still dont understand why i have it - in MariaDB global settings page are external connection allowed for "admin" ( = MariaDB or MySQL "root" in Plesk ) user. (-> Screenshot above)

That's really really strange... when i remember right, i've done the same thing on a Plesk 18.0.x server with Ubuntu 18.x LTS. On that (virtual server), the way i described was working without any issues...
 
Problem still persists - after i unchecked the global settings external access check box for "admin" user then checked [enabled] it again. I was thinking that may work as a workaround for that bug / issue.

But no - doesn't work!!!!!!!
 
"Problem still persists - after i unchecked the global settings external access check box for "admin" user then checked [enabled] it again. I was thinking that may work as a workaround for that bug / issue."

PROOF:

Unbenannt.jpg
 
No, problem was solved in another way... e.g. i can access it via PHPmyadmin (but i still prefer "HeidiSQL" - if it works)

With HeidiSQL (external client on Windows, not Webapp) it works when i enable SSH tunneling - which indicated that root access (on Plesk servers, the MySQL or MariaDB root user is disabled when i remember right - instead of "root", its name is "admin"...?)


I think i would be able to fix it - with GRANT for MySQL/MariaDB admin [root] for IP range '*' - so ALL IPs with the asterisk wildcard.

But i will leave it as it is - because of security issues...
 
@jmar83 The Plesk checkbox that allows the server to accept external connections does exactly that: It allows the server to accept external connections. But this does not automatically authorize individual user accounts such as the "admin" account or others to be used with eternal connections. Your "admin" user is bound to localhost. If you want to allow external logins for that user you must duplicate the dataset, but then, in your duplicate, change the admin name to admin@%, so that all external IPs can login using that user. However, this poses an extremely high risk, because such database logins are not monitored by Fail2Ban, so brute force attacks on your database server will be easy to do, and you won't hardly notice that they are taking place. If you choose to allow admin as an external user, you should rather keep it limited to a specific IP address (your own static DSL landline address for example), e.g. [email protected].
 
@jmar83 , Peter answered your question absolutely correct.
this checkbox makes MariaDB server listen not only on 127.0.0.1, but on all interfaces.
but it does NOT grant access to users.

also, allowing admin user access fro everywhere - is STRICTLY NOT RECOMMENDED AND INSECURE!
 
Back
Top