1 22/05/2026 10 min

Su Ubuntu 20.04 LTS la reimpostazione della password di root non è un’operazione da fare “alla cieca”: prima va chiarito se il problema è davvero la password di root, se l’account è bloccato, oppure se stai lavorando con un sistema che usa sudo e non ha mai avuto root abilitato per accesso diretto. La procedura corretta dipende dal tipo di accesso che hai ancora al server e dal rischio che puoi accettare durante il recupero.

Su una macchina fisica o su una VM con console diretta, il percorso più pulito passa dal menu GRUB e dalla modalità di recupero. Se invece hai accesso SSH con un utente amministrativo, spesso non serve toccare root: basta entrare con sudo -i e verificare lo stato dell’account. Se non hai né console né un utente con privilegi, non c’è una scorciatoia sicura: serve accesso al pannello del provider, alla console seriale o a un processo di rescue autorizzato.

Prima verifica: root è davvero il problema?

Molti casi vengono descritti come “password root persa”, ma in realtà il sistema è configurato per disabilitare il login diretto di root via SSH o per richiedere sudo a un utente nominale. Prima di cambiare qualcosa, controlla il comportamento atteso e quello osservato.

Comportamento atteso: con credenziali corrette dovresti poter entrare come root dalla console locale, oppure ottenere una shell root tramite sudo -i da un utente amministrativo. Comportamento osservato: il login root fallisce, oppure l’account root risulta disabilitato, oppure il prompt SSH rifiuta l’accesso nonostante la password sembri corretta.

Se hai già una sessione con un utente abilitato a sudo, esegui questi controlli:

sudo -i
whoami
passwd -S root
sudo grep -E '^(PermitRootLogin|PasswordAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

L’output utile è semplice: whoami deve restituire root dentro la shell elevata; passwd -S root ti dice se l’account è bloccato o ha una password impostata; la configurazione SSH ti dice se il problema riguarda solo il login remoto e non la password in sé.

Metodo consigliato: reset da recovery mode

Questo è il metodo più lineare quando hai accesso fisico o console virtuale. Non richiede strumenti esterni, non altera dati applicativi e consente un rollback immediato: riavvio normale o uscita dalla shell di recupero. Il blast radius è limitato al filesystem locale e alla sessione di manutenzione.

La logica è questa: avvii in modalità recovery, monti il filesystem in scrittura, cambi la password di root, verifichi lo stato dell’account e riavvii. Se il sistema usa LUKS o una catena di sblocco complessa, devi prima completare lo sblocco del volume come previsto dal tuo ambiente.

1. Riavvia e apri GRUB

Riavvia il server e mostra il menu GRUB. Su molte VM il menu compare tenendo premuto Shift nei BIOS legacy oppure Esc in UEFI. Se il menu non appare, il tempo di pressione è spesso il problema, non il server.

Dal menu seleziona Advanced options for Ubuntu, poi la voce con (recovery mode). Questo porta a un menu di manutenzione con varie opzioni.

2. Entra nella shell di root della recovery

Nel menu recovery scegli root - Drop to root shell prompt. A questo punto, di solito, il filesystem principale è montato in sola lettura. Prima di cambiare la password, devi rimontarlo in scrittura.

mount -o remount,rw /

Verifica che il remount abbia funzionato:

mount | grep ' on / '

Se vedi rw nelle opzioni, sei a posto. Se il filesystem resta in sola lettura, il problema non è la password ma lo stato del disco o del filesystem; in quel caso non forzare altri passaggi prima di controllare i log e lo stato di integrità.

3. Reimposta la password di root

Ora puoi cambiare la password con passwd. Usa una password nuova, lunga e unica; non riutilizzare segreti già presenti su altri sistemi.

passwd root

Il comando chiederà di inserire la nuova password due volte. Se il sistema accetta il cambio, il punto critico è superato. Se invece ricevi un errore, la causa più comune è il filesystem ancora in sola lettura oppure una partizione non montata correttamente.

In alternativa, su alcuni sistemi basta:

passwd

Se sei già nella shell di root, il comando senza argomenti agisce sull’utente corrente. In una recovery shell sei root, quindi il risultato è lo stesso. Io preferisco specificare root quando sto documentando una procedura, perché riduce ambiguità operative.

4. Controlla se root è bloccato o solo senza password valida

Su Ubuntu è possibile che root sia presente ma bloccato. Dopo il reset, verifica lo stato dell’account.

passwd -S root
getent shadow root

Il primo comando mostra lo stato sintetico dell’account; il secondo ti conferma la presenza della riga in shadow. Se il risultato indica un account bloccato, devi capire se il blocco è intenzionale per il tuo scenario operativo oppure se deriva da una policy precedente. In molti ambienti, il blocco di root è una scelta sensata e il vero accesso amministrativo deve avvenire via sudo.

Metodo alternativo: cambio password da utente con sudo

Se hai ancora accesso a un account amministrativo, non serve passare dalla recovery. Questo percorso è meno invasivo e spesso più rapido. Il blast radius è minimo: stai modificando solo le credenziali di root, senza toccare bootloader, filesystem o servizi.

Accedi con il tuo utente e verifica i privilegi:

sudo -l

Se il tuo utente è autorizzato, imposta la nuova password root:

sudo passwd root

Questo è il modo più pulito quando puoi usarlo. Non richiede riavvio e lascia traccia nei log di autenticazione. Su sistemi con audit attivo, il cambio password viene registrato e puoi verificare l’evento in /var/log/auth.log o nel journal, a seconda della configurazione.

Se il login root via SSH resta vietato

Qui c’è un equivoco frequente: reimpostare la password root non significa automaticamente abilitare il login SSH come root. Su Ubuntu, per sicurezza, il login diretto via SSH è spesso disabilitato o limitato a chiavi pubbliche. Quindi puoi avere una password corretta e continuare a non entrare da remoto.

Controlla la configurazione SSH:

sudo grep -R --line-number -E '^(PermitRootLogin|PasswordAuthentication|KbdInteractiveAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Se trovi PermitRootLogin no o una policy equivalente, il comportamento è coerente con il design. In questo caso la soluzione consigliata non è abilitare root via SSH come prima scelta, ma usare un utente nominale con sudo. Se proprio devi consentire l’accesso root da SSH per una finestra di manutenzione, fallo solo temporaneamente, con rollback immediato e con la consapevolezza del rischio.

Esempio di modifica temporanea, da applicare con criterio e con backup del file:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)
sudoedit /etc/ssh/sshd_config

Imposta solo il minimo indispensabile, ad esempio PermitRootLogin prohibit-password se vuoi consentire solo chiavi, oppure yes se hai un requisito operativo ben motivato e temporaneo. Poi valida e ricarica il servizio:

sudo sshd -t && sudo systemctl reload ssh

Se sshd -t fallisce, non ricaricare nulla: correggi prima la sintassi. Il rollback, in caso di errore, è il ripristino del backup e un nuovo sshd -t prima del reload.

Quando il problema non è la password ma il filesystem

Se durante la recovery il filesystem non si rimonta in scrittura, fermati. La password di root non è il primo problema: il sistema potrebbe aver montato la root in sola lettura per errori I/O, journal corrotto, disco quasi pieno o interventi automatici del kernel. In questo caso, cambiare la password senza risolvere il layer storage è solo una distrazione.

Controlli rapidi utili:

dmesg -T | tail -n 80
journalctl -xb | tail -n 100
df -h
lsblk -f

Se vedi errori su ext4, I/O error, blocchi remount in read-only o disco pieno, il fix strutturale va fatto prima del reset definitivo. La verifica minima è semplice: il filesystem deve tornare scrivibile, e i log non devono mostrare nuovi errori al riavvio.

Controlli finali dopo il reset

Dopo aver cambiato la password, esegui una sequenza breve di validazione. Non limitarti a “sembra andare”: verifica il percorso di accesso reale che userai in produzione o in manutenzione.

  1. Esci dalla shell di recovery con exit oppure riavvia con reboot.
  2. Attendi il boot normale e prova l’accesso locale o console con la nuova password.
  3. Se il login è via SSH, verifica prima le policy di sshd e poi prova solo il metodo autorizzato per il tuo ambiente.
  4. Controlla i log di autenticazione: /var/log/auth.log oppure journalctl -u ssh per confermare il tentativo e l’esito.

Comandi utili per la verifica:

sudo journalctl -u ssh -n 50 --no-pager
sudo tail -n 50 /var/log/auth.log

Se il login fallisce ancora ma la password è stata cambiata correttamente, il problema è quasi sempre altrove: policy SSH, shell non valida, account bloccato, PAM, o un problema di tastiera/layout quando si prova in console. Il log ti dice dove guardare, non le impressioni dell’operatore.

Recupero in ambiente cloud o VPS

Su una VPS o su un’istanza cloud, il percorso operativo può cambiare perché spesso non hai accesso al GRUB ma hai una console seriale, un pannello rescue o un disco montabile da un’altra VM. Il principio però resta lo stesso: ottenere una shell di root sul filesystem offline o in recovery, rimontarlo in scrittura, cambiare la password, poi ripristinare il boot normale.

In questi scenari il modo più sicuro è usare la console del provider e il suo flusso di rescue documentato. Se devi staccare il disco e montarlo altrove, fai attenzione ai volumi cifrati, ai UUID e alle entry di /etc/fstab. Una modifica fatta nel posto sbagliato può trasformare un semplice reset in un problema di boot.

Se hai solo accesso al pannello e non alla console, cerca voci come Rescue mode, Serial console, Recovery environment o Reset root password. Molti provider offrono una procedura guidata che evita di intervenire manualmente sui dischi. È spesso la strada meno rischiosa, purché tu la usi con attenzione e con rollback chiaro.

Buone pratiche dopo il recupero

Dopo aver riottenuto l’accesso, non lasciare la situazione “provvisoria” in piedi. La password di root appena impostata dovrebbe essere trattata come credenziale di emergenza, non come accesso operativo quotidiano.

  • Verifica che almeno un utente nominativo abbia privilegi sudo.
  • Disabilita il login root via SSH se non serve davvero.
  • Controlla che l’accesso amministrativo usi chiavi SSH o MFA dove previsto.
  • Ruota eventuali credenziali condivise o documentate male.
  • Aggiorna la procedura interna per indicare come entrare in recovery senza improvvisare.

Se il server è in produzione, vale la regola pratica più semplice: riduci la finestra di esposizione. Ogni modifica temporanea fatta per recuperare l’accesso dovrebbe avere già il suo rollback scritto prima di essere applicata.

Sequenza sintetica da tenere a portata di mano

Quando devi intervenire sotto pressione, questa è la sequenza minima da ricordare: entra in recovery, rimonta in scrittura, cambia la password, verifica lo stato, riavvia, controlla i log. Se hai già un utente con sudo, usa direttamente sudo passwd root e risparmia il boot in recovery.

mount -o remount,rw /
passwd root
passwd -S root
reboot

Questa procedura funziona bene perché separa i problemi: prima accesso al sistema, poi stato del filesystem, poi credenziali, poi validazione. Saltare i passaggi significa spesso perdere tempo su un sintomo e non sulla causa.

Assunzione operativa: il sistema è Ubuntu 20.04 LTS standard, con accesso console o con un utente amministrativo che può usare sudo; se il server usa cifratura disco, LVM complesso o policy SSH personalizzate, la procedura va adattata al flusso di boot e ai vincoli locali.