Accesso negato (utilizzando la password: NO) dal tentativo di accesso al sito remoto tramite nome host quando viene fornita la password

Sto eseguendo uno script php su un server Web in un sito remoto (chiamerò SiteB) che si collega a un server MySql in una posizione remota (chiamerò Sito A). Ora, il server SQL sul sito A ha 2 utenti, uno denominato "usr'@'192.168.1.%" per l'accesso dall'interno della rete interna al sito A e uno denominato "usr'@'client.siteB.com" .

Il server sul sito A è dietro un router e ha tutto il traffico TCP e UDP sulla porta 3306 inoltrato a 192.168.1.12 (l'IP locale del server MySQL sul sito A). Il sito A ha un IP dinamico, tutti i riferimenti al server SQL vengono avviati tramite nome host (chiameremo server.siteA.com). Il sito B ha un IP esterno statico, ma tutte le connessioni SQL che entrano sono indicate solo dal nome host, quindi perché l'utente SQL è 'usr'@'client.siteB.com'.

Il problema che sto riscontrando è che ogni volta che eseguo lo script php dal server web sul sito B, ottengo il seguente errore:

Access denied for user 'usr'@'client.siteB.com' (using password: NO)

Fa anche riferimento a una linea, che è:

$this->MCdbConnection = mysql_connect($this->MySQLhost, $this->MySQLuser, $this->MySQLpassword);

Quindi, come puoi vedere, sto trasmettendo una password. La parte più strana è che eseguendo lo stesso script sulla rete locale nel sito A e cambiando nient'altro che la variabile $ MySQLhost da server.siteA.com a 192.168.1.7, lo script funziona bene, si collega e seleziona e inserisce i dati bene.

Un errore come questo di solito mi fa pensare che sia un problema con il nome utente, ma entrambi gli utenti MySQL ('usr'@'192.168.1.%' e 'usr'@'client.siteB.com') sono completamente identici ed entrambi hanno stessa password e privilegi (solo SELECT, INSERT e UPDATE).

Ho anche avuto lo stesso errore durante il tentativo di connettermi tramite MySQL Workbench e il client della riga di comando da un'altra macchina sulla rete locale nel sito A quando ho lasciato cadere l'utente 'usr'@'192.168.1.%'. Tutti i segni indicano un utente mancante, errato o non autenticato, ma so che l'utente è lì e ha le autorizzazioni appropriate, l'unica cosa che mi rende sospetto è che utilizza un nome host anziché un indirizzo IP.

Ho anche verificato di avere le seguenti regole IPTables impostate sul server MySQL su SiteA:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT

Inoltre, posso e ho eseguito connessioni mysql simili tramite PHP sullo stesso server sul sito B, ma tutte si connettono a localhost.

Inoltre, per buona misura, server SQL presso my.cnf di SiteA:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
general-log
expire_logs_days = 60

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Ho anche provato a cambiare l'host di 'usr'@'client.siteB.com' in '%' ma sto ancora riscontrando lo stesso errore. Inoltre, sto eseguendo il server MySQL su Fedora e ho selinux impostato su permissivo.

Inoltre, ho provato a cambiare il nome host dal nome IP del sito B nell'host dell'utente MySQL, ma ho ancora lo stesso errore. Tuttavia, tutto l'errore che ho visto vederlo si riferiva ad esso come "client.siteB.com", anche quando eseguo un tcpdump su SiteA vedo il traffico proveniente dall'origine "client.siteB.com"

So che gli errori di accesso negato a SQL sono molto comuni e hanno una moltitudine di problemi di root, ma nessuno degli argomenti che ho visto finora su SF sembra risolvere questo problema e sono completamente sconcertato. Inoltre, questa volta il mio google-fu mi ha deluso. :(

Questo errore non è quello che viene fuori mysql_connect, nella mia esperienza; è quello che viene dal mysqlclient della riga di comando. Il tuo script PHP si sta sgretolando alla riga di comando ad un certo punto?

Quindi, ho capito il problema, e si è scoperto che è stato un errore molto ignaro nella mia sceneggiatura php. Quindi, sul server web di SiteB, lo script prende le variabili che memorizzano le informazioni di connessione da un file separato e quel file originariamente aveva delle collisioni con i nomi delle variabili all'interno del mio script dopo che ho fatto un'inclusione. Questo file non esiste nel mio ambiente di test su SiteA, quindi Tutte le variabili per utente, schema, host e password venivano sovrascritte da altre informazioni di connessione che stavo memorizzando nello stesso file per una connessione SQL a localhost che utilizza un password diversa. Quindi, ho dovuto cambiare i nomi delle variabili all'interno dello script e avevo perso una variabile (quella della password), quindi sostanzialmente usava l'altra password quando era su SiteB ma usava la password corretta quando era su siteA.

Quindi, sì, dopo aver corretto quel nome di variabile, la connessione viene ora stabilita e ora viene autenticata correttamente, sto solo riscontrando errori durante la selezione dello schema predefinito per qualche motivo, ma questo sembra essere un problema non correlato. Grazie per l'aiuto a quelli che hanno dato input però.