Come reimpostare la password root su AlmaLinux e Rocky Linux 8 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 14/04/2026 Pubblicato il: 14/04/2026 22:22 Tempo di lettura: 9 min

Quando serve davvero il reset della password root

Su AlmaLinux e Rocky Linux 8 il reset della password di root non si fa “da sistema acceso” se hai perso l’accesso amministrativo: devi intervenire in fase di boot e portarti in una shell con privilegi sufficienti per modificare la password locale. La strada più pulita passa quasi sempre da GRUB, con un avvio temporaneo in modalità di emergenza o single-user. È una procedura di recupero, non una scorciatoia: se il sistema usa cifratura disco, LVM, SELinux o account policy particolari, conviene muoversi con metodo e verifiche minime prima di toccare la password.

La premessa operativa è semplice: devi avere accesso fisico alla console o alla console remota del provider. Se il server è in un datacenter e non hai KVM/IPMI/VNC/serial console, il problema non è la password ma l’accesso al bootloader. In quel caso il primo passo è recuperare il canale di gestione, non forzare tentativi a vuoto.

Questa guida assume un sistema con GRUB2 e kernel standard di AlmaLinux/Rocky 8. Se il disco è cifrato con LUKS, la procedura resta valida ma devi sbloccare la partizione prima di arrivare alla shell di manutenzione. Se invece il sistema usa un’impostazione custom del bootloader o un ambiente di recovery del provider, i passaggi vanno adattati al pannello disponibile.

Scenario operativo: cosa devi ottenere

Obiettivo atteso: arrivare a una shell locale con permessi di root, cambiare la password e riavviare verificando che il login funzioni. Osservato tipico: non conosci la password root, ma il server parte ancora regolarmente e GRUB è accessibile. Se invece il boot si ferma prima del login per errori di filesystem, storage o cifratura, il reset password non basta da solo: prima devi ristabilire l’avvio.

Per evitare errori inutili, ragiona per layer: bootloader, kernel/initramfs, root filesystem, autenticazione. Il reset della password agisce solo sul livello autenticazione locale; non risolve un disco pieno, un filesystem corrotto o un PAM rotto.

Metodo consigliato: avvio temporaneo con GRUB e shell di manutenzione

Questa è la procedura più usata perché è reversibile e non richiede supporti esterni. Il principio è modificare temporaneamente i parametri di boot per entrare in una shell di emergenza, montare il sistema in lettura-scrittura e lanciare passwd.

Riavvia il server e fermati al menu di GRUB. Se il menu è nascosto, tieni premuto Shift o Esc subito dopo il POST, a seconda della piattaforma.
Seleziona il kernel da avviare e premi e per modificarne temporaneamente i parametri.
Trova la riga che inizia con linux o linux16. Alla fine della riga aggiungi uno dei seguenti parametri, a seconda di cosa vuoi ottenere:
```
rd.break
```
oppure, in alcuni casi:
```
init=/bin/bash
```
Se vuoi la via più standard su RHEL-like 8, usa rd.break. È più pulita perché ti porta nel punto giusto della sequenza di avvio per intervenire sul root filesystem.
Avvia con Ctrl+X o F10.

Se tutto va bene, il sistema si fermerà in una shell di emergenza con root sul ramdisk iniziale. A questo punto devi capire se il root filesystem è già montato o no. Di norma con rd.break non lo è ancora nel punto utile al reset, quindi va montato manualmente.

Reset della password con rd.break

Una volta nella shell di emergenza, esegui i passaggi in ordine. L’errore più comune è cambiare la password senza aver rimontato correttamente il filesystem o senza aver sistemato i contesti SELinux. Il risultato è un login che continua a fallire anche se la password è stata aggiornata davvero.

Rimonta il root filesystem in lettura-scrittura:
```
mount -o remount,rw /sysroot
```
Se il comando non restituisce errori, il mount è pronto per la modifica.
Entra nel sistema installato con chroot:
```
chroot /sysroot
```
Da qui operi sul sistema reale, non sul ramdisk di emergenza.
Cambia la password di root:
```
passwd root
```
Inserisci la nuova password due volte. Evita password deboli o riutilizzate: in questo contesto stai recuperando un accesso privilegiato, quindi la rotazione dev’essere seria.
Se SELinux è in enforcing, forza il relabel al prossimo avvio, soprattutto se hai usato init=/bin/bash o hai toccato file sensibili:
```
touch /.autorelabel
```
Questo passaggio evita problemi di contesto che possono bloccare l’accesso al login o a servizi collegati.
Esci dal chroot e sincronizza:
```
exit
sync
```
Riavvia:
```
reboot -f
```
Se il comando non parte per limiti della shell di emergenza, usa il riavvio disponibile dal provider o da console remota.

Dopo il riavvio, prova il login locale o via console con root e la nuova password. Se il sistema rifiuta ancora l’accesso, la causa più probabile non è la password ma un vincolo di policy, un contesto SELinux non riallineato o una configurazione PAM particolare.

Alternativa: init=/bin/bash quando serve una shell ancora più diretta

Il parametro init=/bin/bash porta il kernel ad avviare direttamente una shell Bash al posto del normale init. È utile se rd.break non funziona o se vuoi una via molto lineare, ma ha un costo: ti lascia in un ambiente più grezzo, con meno automatismi e più responsabilità manuale.

In GRUB, modifica la riga del kernel e aggiungi:
```
init=/bin/bash
```
Avvia il sistema. Ti troverai in una shell con root, ma il filesystem root sarà quasi sempre in sola lettura.
Rimonta la root in lettura-scrittura:
```
mount -o remount,rw /
```
Cambia la password:
```
passwd root
```
Se usi SELinux, prepara il relabel:
```
touch /.autorelabel
```
Sincronizza e riavvia:
```
sync
reboot -f
```

Questa strada è pratica, ma meno elegante. Se hai a che fare con filesystem complessi, LVM, RAID software o una root cifrata, rd.break resta in genere più prevedibile.

Se il disco è cifrato con LUKS

Con LUKS la priorità è sbloccare il volume prima della shell di manutenzione. In molti setup, rd.break ti porta comunque abbastanza avanti da poter intervenire, ma se non riesci ad arrivare a un root montabile, devi verificare il flusso di sblocco della cifratura.

Il sintomo tipico è un blocco durante la fase iniziale del boot con richiesta passphrase o un timeout di dracut. In questo caso la password root non è il problema primario: il sistema non riesce proprio ad agganciare il volume di sistema.

Controlla che il prompt LUKS accetti la passphrase corretta dalla console.
Se il sistema non arriva alla shell di emergenza, prova a rimuovere temporaneamente parametri di boot custom e lascia solo rd.break.
Se il problema è un mapping LVM sopra LUKS, verifica la presenza del volume dopo lo sblocco con i comandi disponibili nella shell di dracut:
```
lvm pvscan
lvm vgscan
lvm lvscan
```
Solo dopo aver reso montabile /sysroot ha senso cambiare la password.

Se il volume non si sblocca, il rollback non è nella password ma nel ripristino della passphrase LUKS, nella verifica del keyslot o nella manutenzione del bootloader del provider. Qui non conviene improvvisare: un errore sul layer di cifratura può allungare il downtime più del necessario.

Quando SELinux ti complica il login

Dopo un reset password, il sistema può sembrare “rotto” anche se la password è corretta. Su AlmaLinux e Rocky 8, SELinux in enforcing può bloccare accessi o servizi se i contesti dei file non sono coerenti. È un classico quando si usa una procedura di recovery non standard o si toccano file di autenticazione.

Il controllo minimo, dopo il reboot, è questo:

getenforce
ausearch -m avc -ts recent

Se trovi denials recenti coerenti con il fallimento del login, il problema è quasi certamente di contesto. La correzione meno invasiva è il relabel automatico con touch /.autorelabel prima del riavvio. Se invece il sistema è già avviato e hai accesso via console, puoi analizzare i file coinvolti con restorecon, ma in recovery preferisco il relabel completo quando il rischio è limitato e il tempo di boot aggiuntivo è accettabile.

Verifica finale: non fermarti al solo cambio password

Un reset riuscito non coincide con un accesso confermato. Devi verificare almeno tre cose: che la password sia stata davvero aggiornata, che il login locale funzioni e che non ci siano effetti collaterali su SSH, policy PAM o SELinux. Se il server è in produzione, la differenza tra “ho cambiato la password” e “posso entrare con sicurezza” è il tuo margine operativo.

Accedi via console con root e la nuova password.
Controlla lo stato di SELinux:
```
getenforce
```
Verifica che non ci siano errori recenti di autenticazione:
```
journalctl -b -p warning --no-pager
```
Se usi SSH per l’amministrazione, prova un login da un host di gestione dopo aver confermato l’accesso locale. Non usare questo test come primo tentativo se non sai se la chiave pubblica è ancora valida.

Se il login locale funziona ma SSH no, il problema è altrove: configurazione di sshd, chiavi, PermitRootLogin, firewall o policy di accesso. Il reset della password non tocca quei livelli.

Rollback e blast radius

Il blast radius della procedura è basso se ti limiti a passwd e a un eventuale relabel SELinux. Diventa medio se modifichi parametri di boot in modo persistente, alto se tocchi LUKS, LVM o file di autenticazione senza backup. La regola pratica è semplice: ogni cambio fatto in GRUB deve restare temporaneo, e ogni modifica al filesystem deve avere un modo chiaro per essere annullata o verificata.

Se hai alterato solo la riga di boot in GRUB, nessun rollback è necessario: al riavvio successivo il sistema torna al boot normale, salvo modifiche persistenti fatte da te.
Se hai creato /.autorelabel e il relabel allunga il boot ma poi tutto funziona, lascia completare la procedura. Se invece il sistema resta bloccato, riparti in recovery e analizza i log SELinux prima di rimuovere il file.
Se hai toccato file di autenticazione o PAM, conserva un backup del file originale e ripristinalo solo dopo aver capito il motivo del fallimento. In recovery non si corregge a tentativi un errore di policy.

Assunzione: hai accesso alla console del server e una procedura di recovery standard; se il sistema è cifrato o gestito da un provider con boot personalizzato, verifica prima il canale di accesso e il comportamento del menu di avvio.