Come cambiare la password root su Ubuntu VPS

Come cambiare la password dell'account root del tuo VPS su Ubuntu

Per cambiare la password dell'account root del tuo VPS (server privato virtuale) su Ubuntu, apri una sessione SSH (Secure Shell) come utente autorizzato a eseguire sudo, quindi esegui sudo passwd root. Il comando richiede due volte la nuova password e non richiede quella precedente, perché sudo ha già verificato la tua identità. Per cambiare invece la password del tuo account di accesso, esegui passwd senza argomenti: il comando richiede prima la password corrente.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Questa è l'intera procedura. Tutto ciò che segue riguarda i problemi più comuni: verificare che la nuova password funzioni prima di perdere la sessione con cui potresti correggere l'errore, impostare le password da uno script, farne scadere una intenzionalmente e accedere nuovamente quando la password è già stata persa.

Apri una seconda sessione prima di modificare una password

Apri ora una seconda sessione SSH e lasciala connessa. Quasi tutti gli errori descritti in questa guida si risolvono in due minuti mentre una shell autenticata è ancora attiva; dopo la chiusura dell'ultima sessione, invece, può essere necessario accedere alla console.

Una shell già aperta continua a funzionare anche dopo che modifichi, blocchi o fai scadere l'account a cui appartiene, perché SSH verifica le credenziali al login e non le verifica di nuovo. L'eccezione è sudo. Quando il relativo timestamp scade, sudo verifica nuovamente la password tramite PAM (moduli di autenticazione collegabili), per impostazione predefinita 15 minuti dopo l'ultima richiesta. La nuova password viene quindi verificata realmente la prima volta che sudo la richiede, non durante il login.

Verifica la nuova password nella seconda sessione mentre la prima rimane aperta.

Cambia la tua password con passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully è l'unico output che indica che l'hash in /etc/shadow è stato sostituito. Qualsiasi altro output lascia invariata la vecchia password.

Qui possono verificarsi due errori. passwd: Authentication token manipulation error, seguito da passwd: password unchanged, indica che la password corrente immessa non è corretta oppure che non è possibile scrivere nel filesystem che contiene /etc/shadow. Quest'ultimo è lo stato normale in modalità di ripristino. You must choose a longer password. proviene da pam_unix in /etc/pam.d/common-password, che applica controlli sulla lunghezza e sulla somiglianza per gli utenti normali.

Nella maggior parte delle immagini VPS, l'account predefinito (ubuntu o il nome con cui viene fornito dal provider) non ha una password, ma solo una chiave SSH. passwd non ha una password corrente da verificare, quindi non può superare il primo prompt. Usa invece sudo passwd $USER, che funziona perché il file drop-in sudoers dell'immagine consente a quell'account di eseguire sudo senza password.

Modificare la password di un altro utente con sudo passwd

sudo passwd deploy

A root non viene richiesta la vecchia password e pam_unix ignora i controlli di robustezza applicati agli utenti normali. In questo modo root può impostare una password che l'utente non avrebbe potuto impostare autonomamente.

Il blocco è un'operazione separata. sudo passwd -l deploy inserisce un ! davanti all'hash memorizzato, quindi nessuna password può corrispondere. sudo passwd -u deploy lo rimuove. Leggere nuovamente lo stato con sudo passwd -S deploy.

Bloccare la password non impedisce all'utente di effettuare l'accesso. Qualsiasi chiave presente nel suo ~/.ssh/authorized_keys continua a funzionare, perché l'autenticazione con chiave pubblica non legge /etc/shadow. Per bloccare completamente un account, impostare la scadenza dell'account:

sudo usermod --expiredate 1 deploy

In questo modo la scadenza dell'account viene impostata su una data del 1970 e sshd rifiuta l'accesso indipendentemente dalla credenziale fornita. Annullare l'impostazione con sudo usermod --expiredate '' deploy.

Evitare passwd -d. Imposta una password vuota anziché bloccare l'account e, nelle versioni precedenti che includono ancora nullok nello stack PAM, una password vuota può essere utilizzata da chiunque.

A root deve avere una password su un VPS?

Ubuntu viene distribuito con l'account root bloccato. /etc/shadow contiene ! invece di un hash, e sudo passwd -S root stampa una riga che inizia con root L. Nessuno può accedere come root con una password finché non ne imposti una. Per questo l'immagine fornisce invece un utente abilitato a usare sudo. È consigliabile operare con account utente con privilegi minimi su un VPS anziché come root.

Impostare una password per root offre un solo vantaggio specifico: consente di accedere tramite la console del provider. La console si collega alla macchina virtuale al di sotto dello stack di rete, quindi continua a funzionare quando sshd è configurato in modo errato o una regola del firewall è sbagliata. Tuttavia, comporta anche uno svantaggio. Il menu di ripristino di GRUB richiede la password di root quando l'account root ne ha una. Di conseguenza, lo strumento che useresti per reimpostare una password dimenticata viene protetto proprio da quella stessa password.

Impostare una password per root non consente a root di accedere tramite SSH. Ubuntu viene distribuito con PermitRootLogin prohibit-password, che significa accesso solo tramite chiavi. Verifica quale configurazione usa effettivamente il tuo server:

sudo sshd -T | grep -i permitrootlogin

sshd -T stampa la configurazione effettiva dopo aver risolto ogni riga Include. È quindi l'unica risposta affidabile quando /etc/ssh/sshd_config.d/ contiene file di configurazione aggiuntivi.

Impostare una password da uno script con chpasswd

passwd legge dal terminale e non può essere utilizzato da uno script. chpasswd legge coppie user:password dallo standard input, una per riga.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Funziona, ma inserisce una password in testo in chiaro nella cronologia della shell e nei log di CI (continuous integration). Eseguire prima l'hashing:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 richiede la password due volte senza visualizzare l'input, quindi stampa un hash crypt SHA-512 che inizia con $6$. -e indica a chpasswd che il secondo campo è già sottoposto a hashing, quindi viene copiato in /etc/shadow senza modifiche. L'hash può essere conservato in sicurezza in un repository o in una variabile CI, mentre il testo in chiaro non lascia mai la macchina in cui è stato digitato.

Ubuntu 24.04 esegue l'hashing delle nuove password con yescrypt ($y$) quando passwd le imposta, mentre openssl passwd -6 usa SHA-512. Entrambi i formati vengono verificati al login, perché libxcrypt li supporta entrambi. È possibile combinarli senza problemi e openssl passwd -6 si comporta allo stesso modo in ogni release Ubuntu LTS, a differenza di chpasswd -c YESCRYPT: il pacchetto shadow meno recente di 20.04 non riconosce quel nome di metodo.

Come verificare che la password sia stata effettivamente modificata?

Iniziare dai metadati, quindi verificare con un accesso.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

Il secondo campo indica lo stato: P per una password utilizzabile, L per una password bloccata, NP per l'assenza totale di password. La data indica l'ultima modifica della password, quindi dovrebbe essere quella odierna. I numeri successivi sono i campi relativi all'invecchiamento descritti più avanti.

Il test live più sicuro consiste nell'usare direttamente sudo. sudo -k elimina il timestamp memorizzato nella cache e sudo -v forza una nuova richiesta. Se la nuova password viene accettata, PAM l'ha accettata e la sessione non è stata modificata.

sudo -k && sudo -v

Per testare un altro account, eseguire su - deploy da una shell senza privilegi. Non eseguire sudo su - deploy, perché root non riceve mai una richiesta di password e il test non dimostra nulla. Una password errata restituisce su: Authentication failure.

Il test effettivo consiste in un nuovo accesso SSH dal laptop, mantenendo aperta la sessione operativa:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Qui Permission denied (publickey). indica che il server non ha mai offerto l'autenticazione tramite password, quindi nessuna modifica della password consentirà l'accesso. Permission denied, please try again. indica che l'ha offerta, ma ha rifiutato il valore immesso.

Forzare il cambio della password al prossimo accesso con chage

sudo chage -d 0 deploy

-d 0 imposta la data dell'ultima modifica all'epoca Unix, quindi PAM considera la password scaduta. Al successivo accesso interattivo viene richiesta la password corrente, quindi quella nuova, prima di concedere una shell. sudo passwd -e deploy esegue esattamente la stessa operazione.

Usarlo solo per gli account che effettuano l'accesso interattivo con una password. Una password scaduta influisce anche sugli accessi basati su chiavi, perché sshd esegue la fase account di PAM anche quando l'autenticazione è stata effettuata con una chiave. Un ssh deploy@203.0.113.10 'systemctl restart app' in uno script non riesce e si interrompe con questo messaggio:

Password change required but no TTY available.

Dopo quella riga non viene eseguito nulla e il job restituisce solo un codice di uscita diverso da zero.

Significato dei campi relativi alla scadenza della password

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Questi numeri sono i campi da 4 a 8 della riga dell'utente in /etc/shadow. I giorni minimi (chage -m) indicano per quanto tempo l'utente deve attendere prima di poter cambiare di nuovo la password. In questo modo, dopo una modifica obbligatoria, non può tornare subito alla password precedente. I giorni massimi (chage -M) indicano per quanto tempo la password resta valida. I giorni di avviso (chage -W) indicano quando gli accessi iniziano a mostrare un avviso. I giorni di inattività (chage -I) indicano il periodo di tolleranza successivo alla scadenza, prima che la password non venga più accettata. La scadenza dell'account (chage -E) è una data fissa ed è indipendente dalla password.

sudo chage -M 90 -W 14 deploy

Impostare questo valore solo quando lo richiede una policy. Dal 2017, NIST (il National Institute of Standards and Technology statunitense) sconsiglia la scadenza periodica delle password. Questa pratica spinge gli utenti a creare variazioni prevedibili della stessa password. NIST raccomanda invece di obbligare al cambio quando esistono prove di una compromissione. Una password lunga e univoca conservata in un password manager, insieme all'autenticazione SSH basata su chiavi, è più sicura di un ciclo di 90 giorni.

Cosa fare quando hai perso la password di root

Se un account sul server può eseguire sudo, non c'è nulla da recuperare: sudo passwd root ne imposta una nuova. Il caso più complesso è non avere alcun accesso funzionante.

Per tutto quanto segue è necessaria la console del provider, indicata nella maggior parte dei pannelli come console VNC (virtual network computing) o seriale. Si collega alla macchina virtuale al di sotto dello stack di rete, quindi le impostazioni di sshd e le regole del firewall non la influenzano.

1. Riavvia il server dal pannello e monitora la console.
2. Visualizza il menu di GRUB. Le immagini cloud impostano generalmente GRUB_TIMEOUT=0, quindi tieni premuto Shift durante un avvio BIOS oppure premi ripetutamente Esc durante un avvio UEFI, non appena inizia il riavvio.
3. Seleziona Advanced options for Ubuntu, quindi la voce che termina con (recovery mode) e infine root nel menu di ripristino.
4. Esegui prima mount -o remount,rw /. Il ripristino monta il filesystem root in sola lettura, quindi senza questo passaggio passwd non riesce e restituisce passwd: Authentication token manipulation error perché non può scrivere /etc/shadow.
5. Esegui passwd ubuntu per l'account necessario, quindi riavvia dal pannello.

Se root ha già una password e hai perso proprio quella, la shell di ripristino la richiede e questa procedura non è utilizzabile. Avvia invece l'immagine di ripristino del provider, quindi monta il disco reale e modifica la password al suo interno.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Leggi la struttura delle partizioni con lsblk invece di copiare /dev/vda1 da questa pagina. La partizione root è quella più grande. In un'immagine UEFI si trova accanto a una piccola partizione EFI che non contiene alcuna directory /etc.

Cosa fare quando SSH smette di accettare la password

Lavorate dalla sessione ancora disponibile. Se non è rimasta alcuna sessione, usate la console.

Permission denied, please try again. indica che il server ha offerto l'autenticazione tramite password, ma ha rifiutato ciò che avete inviato. Le cause usuali sono il blocco delle maiuscole attivo oppure un layout della tastiera della console diverso da quello usato quando avete impostato la password.

Permission denied (publickey). indica che il server non ha mai offerto l'autenticazione tramite password. PasswordAuthentication no è impostato in qualche punto e, su Ubuntu 22.04 e versioni successive, di solito si trova in un file drop-in nella directory /etc/ssh/sshd_config.d/, che sovrascrive il file principale. Leggete i valori effettivi:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

La presenza di KbdInteractiveAuthentication yes insieme a PasswordAuthentication no consente comunque l'accesso tramite password, perché il metodo keyboard-interactive usa lo stesso stack PAM. Disattivare uno dei due metodi e lasciare attivo l'altro fa sì che un server apparentemente configurato per usare solo le chiavi continui ad accettare le password digitate.

Too many authentication failures in un messaggio di disconnessione indica che il client ha offerto diverse chiavi prima di arrivare alla password e che il server ha raggiunto MaxAuthTries, il cui valore predefinito è 6. Forzate un solo metodo:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused su una porta che funzionava un minuto prima indica di solito che fail2ban sta monitorando SSH e ha bloccato il vostro indirizzo dopo diversi tentativi non riusciti. La regola di blocco predefinita rifiuta il pacchetto invece di eliminarlo, perciò il rifiuto arriva rapidamente anziché terminare con un timeout. Dalla console, sudo fail2ban-client status sshd elenca gli indirizzi bloccati e sudo fail2ban-client set sshd unbanip 203.0.113.10 rimuove il vostro.

Le password sono un passaggio intermedio, le chiavi sono l'obiettivo finale

Una password che funziona tramite SSH è una password che ogni scanner su Internet può provare a indovinare. Passa all'autenticazione basata su chiavi: i tentativi di indovinare la password non saranno più rilevanti. Genera una coppia di chiavi, installa la parte pubblica e verifica da un secondo terminale che la chiave consenta l'accesso prima di modificare altro. Nozioni di base sulla gestione delle chiavi SSH illustra la generazione, authorized_keys e le passphrase.

Disattiva quindi l'autenticazione tramite password e verifica l'impostazione con sudo sshd -T, invece di fidarti del file che hai modificato. protezione di SSH su un VPS descrive le altre impostazioni di sshd che conviene modificare, mentre i primi dieci minuti su un nuovo VPS le ordina in base alla sequenza da seguire su un server appena installato.

Dopo questa operazione, conserva una password. Un server che consente l'accesso solo tramite chiave e ha una configurazione di sshd non funzionante è raggiungibile soltanto tramite la console del provider, che richiede un nome utente e una password. Un account con una password complessa conservata in un luogo sicuro può fare la differenza tra una correzione di cinque minuti e una reinstallazione.

FAQ

Come posso cambiare la password di root sul mio VPS se non conosco quella precedente?

Accedi con un utente che può eseguire sudo ed esegui sudo passwd root. Imposta una nuova password senza richiedere quella precedente, perché sudo ti ha già autenticato. Se nessun account sul server può eseguire sudo, apri la console del provider, riavvia nel menu di ripristino di GRUB, scegli la voce della shell root, esegui mount -o remount,rw /, quindi esegui passwd. Se root ha già una password e hai perso proprio quella, la shell di ripristino la richiede. In questo caso, l'unica alternativa è usare l'immagine di ripristino del provider, montare il disco ed eseguire chroot.

Perché passwd mostra "Authentication token manipulation error"?

Questa condizione ha due cause. La più comune è una risposta errata al prompt Current password:. La riga passwd: password unchanged sottostante conferma che non è stato scritto nulla. L'altra causa è un filesystem non scrivibile. È ciò che accade nella modalità di ripristino, perché / è montato in sola lettura. Esegui mount -o remount,rw / e riprova.

La modifica della password Linux modifica anche la password di sudo?

Sì. sudo non ha una password propria. Ti autentica tramite PAM usando la stessa voce /etc/shadow utilizzata da SSH e su, quindi ogni account ha una sola password. Per questo il primo prompt sudo dopo una modifica è il test effettivo. Esegui sudo -k && sudo -v per forzare la visualizzazione del prompt mentre hai ancora una sessione funzionante.

La modifica della password interromperà le chiavi SSH o le sessioni aperte?

No. L'autenticazione con chiave pubblica non legge /etc/shadow, quindi le chiavi continuano a funzionare dopo una modifica della password, dopo passwd -l e dopo chage -d 0. Le sessioni già aperte restano attive, perché SSH verifica le credenziali solo al login. L'unico elemento che cambia all'interno di una sessione attiva è sudo, che richiede una volta la nuova password quando scade il relativo timestamp di 15 minuti.

Come posso obbligare un utente a cambiare la password al login successivo?

Esegui sudo chage -d 0 deploy oppure sudo passwd -e deploy, che produce lo stesso effetto. La data dell'ultima modifica memorizzata viene impostata sull'epoch, PAM considera la password scaduta e il login interattivo successivo deve impostarne una nuova prima dell'avvio della shell. Non applicare questa procedura a un account utilizzato dagli script tramite SSH: in tal caso un comando non interattivo restituisce Password change required but no TTY available. e non viene mai eseguito.