Come reimpostare la password root su CentOS 8 e RHEL 8 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 13/05/2026 Pubblicato il: 13/05/2026 08:00 Tempo di lettura: 8 min

Reimpostare la password root su CentOS 8 e RHEL 8 senza improvvisare

Quando la password di root non è più nota su CentOS 8 o RHEL 8, la strada corretta non è cercare scorciatoie: si entra in modalità di emergenza tramite GRUB, si monta il sistema in lettura/scrittura, si interviene sull’account locale e si ripristina il contesto SELinux prima del riavvio. È una procedura di recupero amministrativo, quindi va trattata come un change controllato: accesso fisico o console virtuale, rischio di impatto sul boot, e rollback chiaro se qualcosa non torna.

Il punto chiave è questo: su RHEL 8 e derivate, la password di root si cambia dal sistema installato, non da una “console magica”. Se il server è tuo e hai autorizzazione operativa, il metodo più pulito passa dal parametro rd.break o da una shell di emergenza, a seconda del flusso di boot disponibile. Se invece il nodo è gestito da terzi o non hai controllo della console, il problema non è tecnico ma di accesso: devi recuperare una sessione autorizzata, non forzare il sistema.

Quando usare questa procedura

Usala se hai perso la password root, se l’account è bloccato da una politica locale, oppure se devi ripristinare l’accesso amministrativo dopo un cambio non documentato. Non è la procedura giusta per un singolo servizio rotto, per un utente sudo, o per un problema applicativo: in quei casi conviene prima verificare se basta un account con privilegi delegati o una console di emergenza del provider.

Prima di toccare il boot, chiarisci lo stato atteso vs osservato: ti aspetti di arrivare al login con un account amministrativo noto, ma osservi che nessuna credenziale locale funziona. Se il sistema usa autenticazione centralizzata, directory service o SSO, la password root locale potrebbe non essere il vero collo di bottiglia; in quel caso serve distinguere tra account locale e accesso amministrativo globale.

Prerequisiti e blast radius

Il blast radius è limitato al singolo host, ma l’impatto può essere alto se il nodo ospita servizi critici, storage condiviso o VM. La modifica non tocca i dati applicativi, però può esporre il sistema a errori di boot se si altera in modo errato il contesto SELinux o il mount di root. Il rollback, nella pratica, è il riavvio e il ripristino del boot normale; se hai modificato file di sistema oltre la password, devi avere una copia delle variazioni.

Ti servono: accesso alla console fisica o virtuale, possibilità di fermare e riavviare il nodo, e una finestra in cui un reboot non rompa SLA o dipendenze a valle. Se il server è in produzione, avvisa chi dipende dal servizio: durante la procedura il nodo sarà indisponibile per il tempo del riavvio e del controllo finale.

Procedura consigliata con GRUB e rd.break

Il flusso più affidabile su CentOS 8 e RHEL 8 è usare la shell di emergenza durante l’initramfs, cambiare la password, etichettare correttamente il filesystem e riavviare. I passaggi sotto sono pensati per evitare modifiche permanenti non necessarie.

Riavvia il server e fermati al menu di GRUB. Se il menu non compare, usa il tasto previsto dalla console del provider o della macchina virtuale durante l’avvio.
Seleziona la voce di boot di CentOS/RHEL e premi e per modificarla temporaneamente. Cerca la riga che inizia con linux o linux16.
Alla fine della riga del kernel aggiungi rd.break. In alcuni scenari può essere utile anche enforcing=0 solo per il recupero, ma la prima scelta resta rd.break senza altri cambi inutili.
Avvia con Ctrl+x o F10, a seconda della console. Il sistema si fermerà in una shell di emergenza dell’initramfs.
Verifica di essere nel contesto atteso con:
```
mount | grep ' /sysroot '
cat /proc/cmdline
```
Ti aspetti di vedere /sysroot montato in sola lettura e il parametro rd.break nella command line.
Monta il filesystem reale in scrittura:
```
mount -o remount,rw /sysroot
```
Se il comando fallisce, il problema non è la password ma il mount del root filesystem o un danno al filesystem stesso. In quel caso non andare avanti alla cieca: prima controlla i log della console e lo stato del disco.
Entra nel sistema installato con chroot:
```
chroot /sysroot
```
Ora lavori sul sistema reale, non più sull’ambiente initramfs.
Reimposta la password di root:
```
passwd root
```
Scegli una password forte e coerente con la policy interna. Non lasciare segreti in chiaro in note o ticket.
Se SELinux è attivo, forza la rilabeling al prossimo boot:
```
touch /.autorelabel
```
Questo passaggio evita problemi di contesto dopo il cambio fatto in emergenza. Se lo salti su sistemi con SELinux enforcing, potresti ritrovarti con accessi o servizi che non partono correttamente.
Esci dal chroot e dall’ambiente di emergenza:
```
exit
exit
```
Riavvia il nodo e togli rd.break dal boot temporaneo lasciando l’avvio normale. Se non lo rimuovi, al prossimo boot tornerai nella shell di emergenza.

Se la console è lenta o il menu GRUB è gestito da un hypervisor, può essere più comodo usare la funzione di editing del boot del pannello del provider invece della tastiera locale. L’obiettivo non cambia: aggiungere il parametro solo per quel boot, senza toccare in modo permanente la configurazione di GRUB finché non hai verificato che il recupero sia riuscito.

Alternativa con rescue mode del provider

Se il sistema non consente un accesso affidabile al GRUB o se il filesystem root è corrotto, molti provider offrono una modalità rescue. In quel caso il disco del server viene avviato da un ambiente esterno, il volume viene montato manualmente e la password si cambia offline. È una via utile quando il boot normale non arriva mai a una shell utile.

La logica resta la stessa: individui il volume corretto, lo monti in modo coerente, entri nel filesystem installato, cambi la password e, se necessario, prepari il relabel SELinux. La differenza è che qui il rischio principale è montare il disco sbagliato. Prima di toccare /etc/shadow o il root filesystem, identifica il device con precisione.

Un controllo minimo utile è:

lsblk -f
blkid
mount

Con questi tre comandi verifichi label, filesystem e punti di mount. Se il disco non è quello atteso, fermati: il danno più banale in rescue mode è cambiare l’istanza sbagliata.

Verifiche immediate dopo il cambio

La verifica non è “la password funziona” e basta. Devi controllare che il sistema sia tornato in uno stato coerente, altrimenti il problema si sposta dal recupero accesso a un boot degradato o a servizi non autorizzati da SELinux.

Al login, prova l’accesso con root solo se la policy interna lo consente. In molte installazioni moderne è preferibile usare un account nominale con sudo; se root è disabilitato lato SSH, il cambio password locale non basta a esporre il login remoto.
Controlla il contesto SELinux dopo il boot con:
```
getenforce
sestatus
```
Se il sistema è tornato in Enforcing, bene. Se resta in stato anomalo, verifica la presenza di /.autorelabel o i messaggi di boot.
Verifica che non ci siano errori evidenti nel boot recente:
```
journalctl -b -p err
```
Se compaiono errori di mount, denials SELinux o fallimenti del filesystem, il recupero password è riuscito ma il sistema non è sano. In quel caso va aperto un ticket separato sul problema di root cause.
Se usi accesso remoto root via SSH, controlla la policy in /etc/ssh/sshd_config e la presenza di eventuali restrizioni come PermitRootLogin no. Il cambio della password non modifica queste regole.

Errori frequenti e come riconoscerli in cinque minuti

Il primo errore è dimenticare di rimontare /sysroot in scrittura. Sintomo: passwd può fallire o sembrare riuscito, ma al reboot la password resta invariata. La falsificazione è semplice: dopo il mount -o remount,rw /sysroot, verifica con mount | grep /sysroot che il flag rw sia presente.

Il secondo errore è saltare il relabel SELinux. Sintomo: login apparentemente corretto ma servizi o accessi rifiutati con denial nel journal. La verifica rapida è journalctl -b | grep -i denied e sestatus. Se trovi denials coerenti con il cambio fatto, il rimedio è il relabel e un riavvio pulito.

Il terzo errore è modificare il boot in modo permanente senza bisogno. Se tocchi i file di GRUB invece del boot temporaneo, il blast radius aumenta e il rollback diventa più lento. Per questo, durante il recupero, preferisci sempre la modifica una tantum dal menu di avvio, non la riscrittura della configurazione persistente, salvo necessità documentata.

Se root non serve davvero: meglio sudo e hardening

Dopo il recupero, vale la pena fare una scelta più sana: ridurre l’uso operativo di root e lavorare con account nominativi e sudo. Su sistemi esposti o gestiti da più persone, la password root condivisa è un debito tecnico e operativo. Il recupero di oggi diventa il problema di audit di domani.

Una configurazione minima sensata è: accesso amministrativo tracciato, sudo per i task ordinari, root usato solo per recovery o casi eccezionali, e accesso SSH diretto a root disabilitato quando possibile. Questo non elimina la necessità della procedura di ripristino, ma riduce la probabilità di doverla usare in fretta e sotto pressione.

Se devi documentare il change, annota almeno: data del recupero, motivo, metodo usato, eventuali modifiche a SELinux o GRUB, e chi ha validato il rientro. È il minimo per non ritrovarti tra qualche mese con un host “sistemato” ma senza traccia del perché e del come.

Schema operativo compatto da tenere vicino alla console

Se serve una sequenza rapida, il flusso è questo: entra in GRUB, aggiungi rd.break, avvia, rimonta /sysroot in scrittura, fai chroot, esegui passwd root, crea /.autorelabel, esci e riavvia. Poi controlla login, SELinux e journal. Ogni deviazione da questo schema va motivata da un vincolo reale, non da abitudine o tentativo casuale.

Assunzione operativa: il server è un CentOS 8 o RHEL 8 standard con boot GRUB2, SELinux attivo salvo diversa evidenza, e accesso console autorizzato per il recupero amministrativo.