sql >> Database >  >> RDS >> Mysql

Toegang geweigerd voor gebruiker 'test'@'ip'(met wachtwoord:JA)

"Toegang geweigerd voor gebruiker 'test'@'ip'(met wachtwoord:YES)" is een MySQL-fout.

Dit betekent dat op netwerkniveau alles werkt , omdat de toegang wordt geweigerd als een bepaalde gebruiker , de server moet begrepen hebben met welke gebruiker u verbinding probeerde te maken . Dus netwerk, firewall, routering, enzovoort, moeten allemaal werken; de server moet luisteren, enz.

Het probleem ligt "gewoon" in de authenticatie .

Probeer lokaal verbinding te maken met de database (om de authenticatie te negeren) en inspecteer de privilegetabel:

USE mysql;
SELECT User, Host, Password from user WHERE User = 'test';

en onthoud dat de regel waarin u geïnteresseerd bent degene is die het IP vermeldt (aangezien de foutmelding het IP specificeert , en niet de hostnaam - in dat geval zou het een DNS-probleem kunnen zijn; de hostnaam is de hostnaam waarvan de server denkt dat je er vandaan komt , niet de hostnaam waar je echt vandaan komt).

De gebruiker/host-overeenkomst gaat van meer specifiek tot minder specifiek . Dus als je al had:

user      host     password
test      1.2.3.4  foo

en rende,

GRANT... TO [email protected]'%' ... PASSWORD bar

...deze subsidie ​​zou overal werken behalve 1.2.3.4, waar het wachtwoord 'foo' blijft.

Uit de handleiding (link hierboven):

Je zou kunnen worden gedwongen om te doen

USE mysql;
DELETE FROM user WHERE User = 'test';
GRANT ALL PRIVILEGES ON database.* TO 'test'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

om ervoor te zorgen dat er geen valse regels in de toekenningstabel zijn die verwijzen naar de gebruiker 'test'.

(Ook zou de GRANT, denk ik, moeten zijn

GRANT ALL PRIVILEGES ON databasename.*

)

Twijfel aan beveiliging (niet gerelateerd aan het antwoord)

De handleiding hierboven zegt:De specificiteit van een letterlijk IP-adres wordt niet beïnvloed door het feit of het een netmasker heeft, dus 192.168.1.13 en 192.168.1.0/255.255.255.0 worden als even specifiek beschouwd .

Nu op het eerste gezicht 127.0.0.1/0.0.0.0 lijkt erg specifiek (en ongevaarlijk) voor localhost . Het netmasker, als ik me niet vergis, zorgt ervoor dat het gelijk is aan % , behalve dat het ongelooflijk specifiek is en als eerste wordt uitgevoerd . Daarom

test     bar         %           
test     localfoo    127.0.0.1/0.0.0.0

betekent dat het wachtwoord voor test overal is het helemaal geen "bar", maar het is "localfoo".

Niemand zou zo'n subsidie ​​per ongeluk invoeren, maar er is een fout en een fout .



  1. Waarom zegt Postgres dat column niet bestaat?

  2. Is het veilig om LIMIT te gebruiken zonder ORDER BY

  3. MySQL:controleer of de gebruiker bestaat en laat deze vallen

  4. PostgreSQL Cloud Vendor Lock-in vermijden