Come reimpostare la password root di MySQL

Quando la password di root di MySQL è persa, il punto non è “forzare” l’accesso, ma rientrare in modo controllato, con il minor blast radius possibile e con un rollback chiaro. La procedura cambia poco tra installazioni recenti, ma cambia abbastanza tra MySQL 5.7, MySQL 8.0 e sistemi dove l’account amministrativo non è davvero root ma un utente con privilegi equivalenti. La strada più pulita resta sempre la stessa: fermare il servizio, avviarlo temporaneamente senza verifica dei privilegi, entrare in locale, cambiare la credenziale, riattivare il controllo normale e verificare che il servizio torni sano.

Questo è un caso da trattare come change controllato su un servizio di produzione. L’obiettivo atteso è semplice: l’account amministrativo deve tornare accessibile con una nuova password, senza corrompere tabelle di sistema, senza lasciare il server in modalità insicura e senza perdere la capacità di rollback. L’osservazione da fare prima di toccare tutto è altrettanto semplice: il demone MySQL deve essere identificato correttamente, la directory dati deve essere coerente e deve esistere un modo per riavviare il servizio nel suo stato normale.

Prima di intervenire: cosa verificare davvero

La prima distinzione utile è tra password persa e account non raggiungibile per un altro motivo. Se il problema è un errore di rete, un socket diverso dal previsto, un lock di filesystem o un servizio fermo, cambiare la password non risolve nulla. Prima di procedere, conviene confermare tre cose: che MySQL sia in esecuzione o arrestabile, che il socket locale sia quello atteso e che non ci siano errori di storage o crash loop.

Su sistemi con systemd, un controllo minimo è questo:

systemctl status mysql --no-pager

L’esito atteso è un servizio active (running) oppure inactive ma gestibile. Se vedi failed, guarda subito i log recenti prima di cambiare la procedura:

journalctl -u mysql -n 100 --no-pager

Se il servizio ha un nome diverso, spesso è mysqld o una variante del package. Il controllo del socket locale aiuta a capire se stai puntando all’istanza giusta:

ss -ltnp | grep 3306

Se MySQL risponde sulla porta prevista ma l’accesso fallisce solo con la password, il problema è coerente con un reset credenziali. Se invece non compare nessun listener, il tema è prima di tutto operativo e va risolto il servizio, non l’account.

MySQL 5.7 e 8.0: la logica è la stessa, il dettaglio cambia

La tecnica classica per recuperare l’accesso amministrativo consiste nell’avviare MySQL con la verifica dei privilegi disattivata. In quel momento il server accetta connessioni locali senza controllare gli account, così puoi entrare e impostare una nuova password. Questa modalità va usata solo per il tempo strettamente necessario e solo su accesso locale o su una finestra di manutenzione ben controllata.

Il flusso operativo è questo: arresti MySQL, lo riavvii con --skip-grant-tables e, se serve, con il socket locale esplicito; poi ti connetti come amministratore senza password, aggiorni la credenziale e torni al funzionamento normale. La differenza principale tra 5.7 e 8.0 sta nel comando SQL da usare per cambiare la password e nel plugin di autenticazione predefinito.

Arresto pulito del servizio

Prima di tutto ferma il demone in modo ordinato:

systemctl stop mysql

Se il servizio si chiude male o resta appeso, controlla i log e verifica che non ci siano transazioni lunghe o I/O bloccato. Non forzare subito il kill se non hai prima guardato lo stato del processo e del filesystem.

Avvio temporaneo senza controllo privilegi

Il metodo più comune è avviare MySQL con opzione temporanea da unit override o da riga di comando, a seconda di come è installato. Su molte distribuzioni conviene usare un override temporaneo del servizio, così il rollback è immediato e non lasci modifiche sparse.

In alternativa, per un test rapido e locale, puoi avviare il demone manualmente con una configurazione minima. L’importante è non esporlo in rete mentre i grant sono disattivati.

mysqld_safe --skip-grant-tables --skip-networking &

La presenza di --skip-networking riduce il rischio: nessun client remoto deve poter sfruttare la finestra di manutenzione. Se il server usa systemd e l’avvio manuale non è coerente con l’installazione, preferisci un override del servizio o una modalità di recovery documentata dal package.

Connessione locale di emergenza

Una volta avviato il server in modalità di recupero, entra localmente:

mysql -u root

Se l’istanza richiede esplicitamente il socket, aggiungilo con --socket. L’obiettivo è ottenere il prompt SQL senza autenticazione, ma solo dal nodo locale.

Reset su MySQL 8.0

Su MySQL 8.0 la via più pulita è usare ALTER USER. Se l’account si chiama davvero root e l’host è localhost, il comando tipico è:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'NuovaPasswordForte';

Se l’account usa un plugin diverso o un host diverso, verifica prima i record presenti in mysql.user e non dare per scontato che esista solo una riga. In molti ambienti amministrativi l’utente è root su localhost, ma in altri casi c’è un account dedicato con privilegi equivalenti.

Dopo il cambio, se l’istanza usa caching dei privilegi o se vuoi forzare una coerenza immediata, puoi eseguire:

FLUSH PRIVILEGES;

Su 8.0, se l’account è configurato con plugin di autenticazione specifici, conviene verificare che il plugin resti quello atteso. Il reset password non deve trasformare di nascosto il metodo di login.

Reset su MySQL 5.7

Su MySQL 5.7 il comando dipende dalla configurazione, ma ALTER USER è comunque preferibile quando disponibile. In installazioni più vecchie o particolari, può essere ancora presente il flusso con SET PASSWORD. Un esempio classico è:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('NuovaPasswordForte');

Se il server rifiuta questo approccio perché il plugin o la versione non lo supportano, passa a ALTER USER. Non mischiare i due metodi senza aver prima capito quale sintassi è accettata dall’istanza in uso.

Se root non è root: account amministrativo equivalente

In parecchi ambienti la gestione operativa non usa l’utente root, ma un altro account con privilegi completi su uno o più host. In questo caso il reset va fatto sull’account reale, non su un nome “di comodo”. La verifica minima è guardare gli account presenti nella tabella dei grant e capire quale combinazione utente/host viene usata davvero.

Se sei già entrato in modalità di recupero, puoi ispezionare gli account così:

SELECT User, Host, plugin FROM mysql.user;

Questa query ti dice se esistono più varianti dello stesso utente e quale plugin di autenticazione è associato. È un passaggio importante, perché cambiare la password del record sbagliato lascia il problema identico e crea confusione al riavvio.

Una volta individuato l’account corretto, usa il comando coerente con la versione e con il plugin atteso. Se l’accesso amministrativo passa attraverso un account nominato diversamente, il reset deve rispettare quel record specifico. In caso di dubbio, annota host, plugin e privilegi prima di modificare qualunque cosa.

Quando il servizio usa systemd

Su installazioni moderne con systemd, il modo più sicuro per lavorare è creare una finestra di manutenzione controllata, fermare il servizio e riattivarlo con gli stessi parametri di base, senza lasciare modifiche permanenti se non serve. Se devi fare un override temporaneo, mantienilo piccolo e reversibile.

Per vedere come è definita l’unità del servizio:

systemctl cat mysql

Se il package usa un nome diverso, controlla mysqld. L’idea è capire dove inserire un parametro temporaneo senza alterare la configurazione di produzione. Se hai bisogno di un avvio di recupero persistente per pochi minuti, documenta subito il rollback e rimuovi l’override appena cambiata la password.

Un approccio pratico è usare un file drop-in temporaneo in /etc/systemd/system/mysql.service.d/ solo se sai esattamente come viene caricato il servizio. Dopo il reset, ricarica systemd e torna alla configurazione normale:

systemctl daemon-reload
systemctl restart mysql

Se il riavvio fallisce, non insistere con tentativi ciechi: torna ai log e verifica che non sia rimasto un parametro di recovery attivo o un errore di configurazione nel file di unità.

Quando entra in gioco InnoDB recovery

Se MySQL non parte per problemi di InnoDB, il reset password diventa secondario: prima devi far ripartire il motore abbastanza da consentire l’accesso amministrativo. In questi casi si lavora con una recovery progressiva, aumentando il livello solo quanto basta per stabilizzare il server e leggere i grant.

Il punto chiave è non confondere un crash di storage con un problema di autenticazione. Se nei log trovi errori su redo log, tablespace o corruption, la password non è il blocco principale. Prima si recupera la disponibilità minima del motore, poi si cambia la credenziale.

Un controllo utile è leggere gli ultimi messaggi del log applicativo o di sistema. A seconda dell’installazione, il file può stare in un percorso come /var/log/mysql/error.log oppure essere gestito da journal. Cerca errori come InnoDB: corruption, Unable to lock, Redo log o Table mysql.user doesn't exist. Quest’ultimo è un campanello d’allarme serio: se le tabelle di sistema sono danneggiate, il reset password richiede un percorso di ripristino più ampio.

Se l’istanza richiede un avvio con opzioni di recovery, procedi con il livello minimo che consente il login locale. Non alzare il livello più del necessario, perché ogni step in più riduce la sicurezza e aumenta il rischio di scrittura incompleta. Dopo aver recuperato l’accesso, esegui il reset e pianifica la verifica dell’integrità del dataset appena possibile.

Verifica finale dopo il cambio password

Dopo il reset, il test vero non è solo “la password funziona”, ma “il servizio è tornato nel suo stato normale e l’accesso amministrativo è coerente”. Riattiva MySQL senza opzioni di recovery, poi prova il login con la nuova password da shell locale.

systemctl restart mysql
mysql -u root -p

Se l’accesso riesce, verifica che l’istanza risponda e che i privilegi siano intatti. Una query minima utile è:

SHOW DATABASES;

Se i database di sistema compaiono e non ci sono errori di autenticazione, il reset è andato a buon fine. A questo punto controlla anche che non sia rimasto alcun parametro di emergenza attivo nel servizio o nella configurazione.

Rollback e punti di attenzione

Il rollback, in questo caso, non è tornare alla vecchia password: se l’hai persa, non è un’opzione utile. Il rollback vero è riportare il server alla configurazione standard, rimuovere eventuali override temporanei e confermare che la modalità di recupero sia stata disattivata. Se hai modificato file di unità o snippet di configurazione, conserva il diff o il backup prima di chiudere il change.

Se qualcosa non torna dopo il riavvio, i sintomi più utili da osservare sono questi: il servizio non parte, il login fallisce ancora, compare un errore di plugin, oppure MySQL accetta il login ma non carica correttamente i grant. In ognuno di questi casi la verifica successiva deve essere mirata ai log e alla configurazione, non a nuovi tentativi casuali di reset.

Assunzione: l’istanza è locale o accessibile in console, il servizio è gestito da systemd nella maggior parte dei casi, e l’account amministrativo è un utente MySQL con privilegi completi su localhost o su un host noto.