Impostare la password di root in Ubuntu 20.04 LTS

Perché la password di root è disabilitata su Ubuntu 20.04 LTS

Su Ubuntu 20.04 LTS l’account root non è pensato per l’uso operativo quotidiano. Dopo l’installazione, il sistema privilegia sudo per le attività amministrative e lascia root bloccato, così da ridurre il rischio di accessi diretti e di password condivise tra più operatori. In pratica, il login come root non è il percorso normale: si parte da un utente amministrativo e si elevano i privilegi quando serve.

Impostare una password per root ha senso in scenari precisi: recovery locale, procedure legacy, ambienti con console limitata, automatismi che richiedono un account superuser tradizionale, oppure migrazioni da sistemi vecchi dove il modello operativo non è ancora stato ripulito. Fuori da questi casi, la scelta migliore resta sudo con tracciabilità dei comandi e password personale dell’operatore.

La differenza importante è questa: abilitare la password di root non cambia i privilegi del sistema, cambia solo il modo in cui si accede a quei privilegi. Il blast radius non è teorico: se la password finisce in mani sbagliate, l’accesso è completo. Per questo la decisione va trattata come un change controllato, non come una scorciatoia da fare “tanto per”.

Quando serve davvero e quando no

Usare root direttamente può essere giustificato quando il contesto tecnico lo impone. Un esempio classico è il recupero di un sistema dove sudo non è più utilizzabile perché l’utente amministrativo è stato rimosso, il gruppo corretto non è più configurato, oppure la macchina è in una fase di manutenzione in cui si lavora da console locale o da rescue environment. Un altro caso è l’uso di strumenti o procedure legacy che non supportano bene l’escalation tramite sudo.

Non è invece una buona idea usare root come account primario di lavoro. Se un operatore sbaglia un comando da root, l’impatto è immediato e ampio. Se invece lavora con sudo, almeno c’è un confine operativo e una traccia nei log. In ambienti condivisi, root dovrebbe essere più vicino a una chiave di emergenza che a una credenziale d’uso corrente.

Prima di abilitare la password, conviene verificare se la necessità è reale. Spesso il problema non è root, ma un utente senza privilegi corretti, una policy sudoers incompleta o un accesso SSH configurato male. In molti casi la soluzione migliore è correggere il modello di accesso, non aprire root al login diretto.

Verificare lo stato attuale dell’account root

Il primo controllo è capire se root è effettivamente bloccato e se il sistema accetta già un accesso privilegiato alternativo. Da un utente con privilegi amministrativi, controlla lo stato dell’account e della password in modo non distruttivo.

Comandi utili:

sudo passwd -S root
sudo grep '^root:' /etc/shadow
id
sudo -l

Nel primo comando, un output con stato bloccato indica tipicamente una password non impostata o una marcatura che impedisce il login diretto. Nel secondo, la voce di root in /etc/shadow mostra se il campo password contiene un hash valido o un prefisso di lock. Il terzo e il quarto servono a confermare che l’utente corrente ha davvero la capacità di amministrare il sistema prima di toccare root.

Se sudo -l fallisce, non hai un problema di root: hai un problema di delega. In quel caso la soluzione è sistemare prima il privilegio dell’utente amministrativo, altrimenti sblocchi root ma non risolvi il punto operativo che ti ha portato lì.

Impostare la password di root in modo controllato

La procedura base è semplice, ma va fatta con criterio. Da un account che già dispone di sudo, imposta la password di root con il comando dedicato. Questo aggiorna la credenziale dell’account senza toccare altri utenti.

sudo passwd root

Il sistema chiederà di digitare e confermare la nuova password. Se il comando va a buon fine, l’account root avrà una password valida per l’autenticazione locale e, a seconda della configurazione, anche per l’accesso remoto. Qui sta il punto delicato: non basta impostare la password, bisogna decidere dove quella password può essere usata.

Dopo l’impostazione, verifica lo stato:

sudo passwd -S root

Un controllo utile è anche testare il passaggio a root dalla sessione locale, senza aprire subito accessi remoti:

su -

Se il comando chiede la password e l’accesso riesce, hai conferma che la credenziale funziona. Se fallisce, controlla prima se la tastiera è corretta, poi lo stato dell’account con passwd -S e infine eventuali policy PAM che limitano l’accesso locale.

Se vuoi solo sbloccare root senza esporlo inutilmente

In alcuni casi il requisito non è “abilitare root ovunque”, ma solo renderlo disponibile per operazioni locali o di recovery. Questa è la scelta meno rischiosa. In pratica, imposti la password, ma lasci chiuso l’accesso SSH diretto a root. Così mantieni un canale di emergenza senza trasformare il server in un bersaglio più facile da attaccare via rete.

Il punto da controllare è la configurazione di SSH. Su Ubuntu, la direttiva da verificare è in /etc/ssh/sshd_config o nei file inclusi da quella configurazione. La voce tipica è PermitRootLogin. Se vuoi evitare il login remoto diretto, deve restare su un valore restrittivo come no o, in certi casi, prohibit-password a seconda della policy adottata.

Verifica la configurazione attiva con:

sudo sshd -T | grep -i permitrootlogin

Se il risultato mostra che root è ammesso via password, stai ampliando la superficie d’attacco. Se questo non è voluto, correggi la policy prima di riavviare SSH. Il controllo con sshd -T è preferibile al solo file statico perché riflette l’effettiva configurazione risultante dopo include e override.

Scelta operativa consigliata: root sì, login remoto no

La configurazione più sensata nella maggior parte dei casi è questa: root ha una password, ma l’accesso remoto diretto resta disabilitato. In questo modo puoi usare root in console, in recovery o tramite su -, ma non offri un target diretto su SSH. È un compromesso pragmatico, soprattutto in ambienti dove vuoi un account di emergenza ma non vuoi aprire un canale amministrativo troppo facile da bruteforzare.

Per allineare la configurazione a questa scelta, puoi lasciare intatta la password di root e bloccare l’accesso diretto via SSH. La modifica va fatta con attenzione, perché un errore qui può chiuderti fuori dalla macchina. Prima di cambiare qualsiasi direttiva, assicurati di avere una sessione aperta valida e un accesso alternativo funzionante.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F_%H%M%S)

Dopo il backup, modifica il file e imposta la policy desiderata. Se usi editor testuale, il valore di riferimento da cercare è:

PermitRootLogin no

Poi valida la sintassi prima di ricaricare il servizio:

sudo sshd -t

Se il controllo non produce output, la sintassi è corretta. Solo a quel punto puoi applicare la modifica con un reload di SSH, che è meno rischioso di un restart completo in molti casi:

sudo systemctl reload ssh

Se la tua distribuzione o il tuo setup usano un nome servizio leggermente diverso, verifica con systemctl status ssh o systemctl status sshd. Su Ubuntu il servizio è normalmente ssh.

Gestione della password: robustezza, rotazione e tracciabilità

Una password di root non va trattata come una credenziale ordinaria. Deve essere lunga, non riusata, conservata secondo la policy dell’organizzazione e ruotata se sospetti esposizione. Se la stai introducendo perché il sistema prima non ne aveva una, documenta il motivo e il perimetro d’uso: locale, console, recovery, o solo manutenzione straordinaria.

Evita di scriverla in chiaro in ticket, note operative o script. Se serve condividerla tra più persone, usa un password manager con controllo accessi e audit. In ambienti seri, il vero problema non è “dove la metto oggi”, ma “come faccio a sapere chi l’ha vista e quando”.

Se la credenziale root è necessaria solo per una finestra temporanea, pianifica già la disabilitazione. In quel caso il ciclo corretto è: abilita, esegui l’intervento, verifica, poi blocca di nuovo. Lasciare root aperto dopo la manutenzione è una delle abitudini peggiori, perché l’eccezione diventa configurazione permanente senza che qualcuno se ne accorga.

Verifiche dopo l’abilitazione

Dopo aver impostato la password, verifica almeno tre cose: che root sia realmente autenticabile, che l’accesso remoto sia coerente con la policy, e che i log mostrino il comportamento atteso. I log sono la prova più utile quando devi capire se l’operazione ha introdotto un rischio non previsto.

Controlli pratici:

1. Test locale con su - da una sessione amministrativa già aperta.
2. Verifica SSH con sshd -T | grep -i permitrootlogin.
3. Controllo dei log di autenticazione con sudo journalctl -u ssh -n 50 --no-pager oppure, se presente, sudo tail -n 50 /var/log/auth.log.

Nel log cerca sia i tentativi riusciti sia quelli negati. Se hai lasciato il login remoto disabilitato, un tentativo di accesso come root via SSH deve essere respinto in modo netto e registrato. Se invece il login è consentito solo in casi specifici, assicurati che la policy corrisponda davvero al comportamento osservato.

Recovery: come tornare indietro senza perdere controllo

Il rollback più semplice, se hai solo impostato la password, è bloccare di nuovo root quando non serve più. Su Ubuntu puoi farlo con un lock dell’account oppure con la rimozione della password, a seconda della policy interna. La scelta va fatta in base a come vuoi che il sistema reagisca agli accessi di emergenza: account inutilizzabile del tutto o account mantenuto per uso locale con login remoto chiuso.

Un rollback prudente per un ambiente standard consiste nel riportare root a uno stato non usato per login quotidiano e nel mantenere accessi amministrativi via sudo. Se hai modificato SSH, conserva il backup del file di configurazione finché non hai completato i test di accesso da un secondo canale. Non fare mai il cambio da remoto senza una sessione di riserva già pronta: è il classico caso in cui l’errore non si vede finché non sei tagliato fuori.

sudo passwd -l root

Dopo il lock, ricontrolla lo stato:

sudo passwd -S root

Se hai toccato SSH e vuoi tornare alla versione precedente, ripristina il backup e valida prima di ricaricare il servizio:

sudo cp /etc/ssh/sshd_config.bak.YYYY-MM-DD_HHMMSS /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh

La sostituzione del timestamp è volutamente manuale: non usare comandi “creativi” se non sei certo del file corretto da ripristinare. Il rollback deve essere banale da eseguire e facile da verificare.

Procedura compatta consigliata

Se vuoi una sequenza essenziale e pulita, questa è la versione da operatore:

1. Verifica che l’utente corrente abbia sudo con sudo -l.
2. Imposta la password di root con sudo passwd root.
3. Controlla lo stato con sudo passwd -S root.
4. Decidi se limitare l’uso al locale o anche al remoto.
5. Se SSH è coinvolto, verifica sshd -T | grep -i permitrootlogin prima di cambiare nulla.
6. Applica eventuali modifiche con backup del file, validazione sintattica e reload del servizio.
7. Prova l’accesso, controlla i log e poi definisci se il root va lasciato attivo o richiuso.

Questa sequenza evita il classico errore di cambiare subito la configurazione remota senza avere una prova locale che la password funzioni. È una differenza piccola, ma in produzione fa la differenza tra un intervento ordinato e una sessione di recupero a freddo.

Cosa tenere a mente in ambiente server

Su un server Ubuntu 20.04 LTS la domanda giusta non è “come abilito root?”, ma “qual è il minimo livello di accesso necessario per ottenere il risultato senza aumentare il rischio?”. Se basta sudo, non toccare root. Se root serve per emergenza, abilitalo con un perimetro chiaro e con una data di revisione. Se devi esporlo via rete, fallo solo dopo aver valutato autenticazione, logging e hardening di SSH.

La regola pratica è semplice: abilita solo ciò che puoi controllare, e controlla solo ciò che puoi revocare rapidamente. Root con password su Ubuntu non è un problema in sé; diventa un problema quando manca la disciplina operativa intorno a quella scelta. In un ambiente ben gestito, dovrebbe restare un’eccezione documentata, non una scorciatoia permanente.

Se il tuo obiettivo è standardizzare l’accesso amministrativo, la strada migliore è rafforzare sudo, usare account nominativi, registrare i comandi e tenere root bloccato. Se invece stai costruendo una procedura di recovery, allora root con password ha senso, ma solo insieme a una procedura di chiusura già scritta e testata. È lì che si vede se la configurazione è davvero sotto controllo.