Come cambiare la password root su un VPS Ubuntu

Come modificare la password dell'account root del VPS su Ubuntu

Per modificare la password dell'account root del VPS (virtual private server) su Ubuntu, apri una sessione SSH (secure shell) con un 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 modificare invece la password del tuo account di accesso, esegui passwd senza argomenti. In questo caso, il comando richiede prima la password attuale.

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

Questa è l'intera procedura. Il resto della guida tratta i problemi più comuni: verificare che la nuova password funzioni prima di perdere la sessione da cui potresti ripristinarla, impostare password da uno script, forzarne la scadenza e recuperare l'accesso quando la password è già stata persa.

Apri una seconda sessione prima di modificare una password

Apri subito una seconda sessione SSH e lasciala connessa. Quasi tutti i problemi descritti in questa guida si risolvono in due minuti finché una shell autenticata è ancora attiva; dopo la chiusura dell’ultima sessione, invece, è necessario accedere tramite console.

Una shell già aperta continua a funzionare anche dopo la modifica, il blocco o la scadenza dell’account a cui appartiene, perché SSH verifica le credenziali al login e non le ricontrolla in seguito. L’eccezione è sudo. Dopo la scadenza del relativo timestamp, sudo verifica nuovamente la password tramite PAM (moduli collegabili per l’autenticazione). Per impostazione predefinita, il timestamp scade 15 minuti dopo l’ultima richiesta. Di conseguenza, la nuova password viene verificata realmente la prima volta successiva in cui sudo la richiede, non al login.

Verifica la nuova password nella seconda sessione, lasciando aperta la prima.

Modificare la propria 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 risultato lascia invariata la vecchia password.

Qui si verificano due errori. passwd: Authentication token manipulation error, seguito da passwd: password unchanged, indica che la password corrente immessa è errata oppure che il filesystem che contiene /etc/shadow non è scrivibile; questa è la condizione normale nella 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 oppure il nome assegnato dal provider) non ha alcuna password, ma solo una chiave SSH. passwd non ha una password corrente da verificare e non può quindi 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 non applica i controlli di robustezza previsti per gli utenti normali. Di conseguenza, 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ò corrispondervi. sudo passwd -u deploy lo rimuove. Verificare lo stato con sudo passwd -S deploy.

Il blocco della password non impedisce all'utente di effettuare l'accesso. Qualsiasi chiave presente in ~/.ssh/authorized_keys continua a funzionare, perché l'autenticazione con chiave pubblica non legge /etc/shadow. Per bloccare completamente un account, impostarne la scadenza:

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 invece di bloccare l'account e, nelle release meno recenti che includono ancora nullok nello stack PAM, una password vuota può essere utilizzata da chiunque.

È necessaria una password per root su un VPS?

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

Impostare una password per root offre un solo vantaggio: consente di accedere tramite la console del provider. La console si collega alla macchina virtuale al di sotto dello stack di rete. Continua quindi a funzionare quando sshd è configurato in modo errato o una regola del firewall è sbagliata. Ha però anche un costo. Il menu di ripristino di GRUB richiede la password di root quando l'account root ne ha una. Lo strumento che useresti per reimpostare una password dimenticata viene quindi protetto dalla stessa password.

Impostare una password per root non consente a root di accedere tramite SSH. Ubuntu viene distribuito con PermitRootLogin prohibit-password, che consente soltanto l'autenticazione tramite chiavi. Controlla quale configurazione usa effettivamente il 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 drop-in.

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 chiaro nella cronologia della shell e nei log della 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 i caratteri digitati, quindi stampa un hash SHA-512 crypt che inizia con $6$. -e indica a chpasswd che il secondo campo contiene già un hash, quindi questo viene copiato in /etc/shadow senza modifiche. L’hash può essere conservato in sicurezza in un repository o in una variabile della CI, mentre la password in chiaro non lascia mai la macchina su cui è stata digitata.

Ubuntu 24.04 applica yescrypt alle nuove password ($y$) quando passwd le imposta, mentre openssl passwd -6 utilizza SHA-512. Entrambi i formati vengono verificati durante l’accesso, perché libxcrypt legge entrambi. È possibile utilizzarli insieme senza problemi. openssl passwd -6 si comporta allo stesso modo in ogni release Ubuntu LTS, mentre chpasswd -c YESCRYPT no: il pacchetto shadow meno recente di 20.04 non riconosce il nome di quel metodo.

Come verificare che la password sia stata effettivamente modificata?

Inizia dai metadati, quindi verifica il risultato 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 se non è presente alcuna password. La data indica l'ultima modifica della password, quindi dovrebbe corrispondere a oggi. I numeri successivi sono i parametri di scadenza descritti più avanti.

Il test live più sicuro è 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 convalidata e la sessione non ha subito modifiche.

sudo -k && sudo -v

Per verificare un altro account, esegui 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 stampa 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). significa che il server non ha offerto l'autenticazione tramite password, quindi nessuna modifica della password consentirà l'accesso. Permission denied, please try again. significa che l'ha offerta, ma ha rifiutato il valore immesso.

Forzare il cambio della password al login successivo con chage

sudo chage -d 0 deploy

-d 0 imposta la data dell'ultima modifica all'epoch, quindi PAM considera la password scaduta. Al login interattivo successivo 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 il login interattivo con una password. Una password scaduta influisce anche sui login basati su chiave, perché sshd esegue la fase account di PAM anche quando l'autenticazione è stata eseguita con una chiave. Un ssh deploy@203.0.113.10 'systemctl restart app' eseguito da uno script non interattivo fallisce con questo messaggio e si interrompe:

Password change required but no TTY available.

Non viene eseguita alcuna istruzione successiva a quella riga e il job segnala soltanto 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 corrispondono ai 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 modificare nuovamente la password. Questo impedisce di ripristinare subito la password precedente dopo una modifica obbligatoria. 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 visualizzare un avviso. I giorni di inattività (chage -I) indicano il periodo di tolleranza dopo la scadenza, prima che la password non venga più accettata. La scadenza dell'account (chage -E) è una data fissa e non dipende dalla password.

sudo chage -M 90 -W 14 deploy

Impostare questo valore solo quando previsto da una policy. Dal 2017 il NIST (il National Institute of Standards and Technology degli Stati Uniti) sconsiglia la scadenza periodica delle password, perché spinge gli utenti a usare variazioni prevedibili della stessa password. Il NIST raccomanda invece di imporre una modifica quando vi sono evidenze di compromissione. Una password lunga e univoca conservata in un password manager, insieme all'autenticazione SSH basata su chiavi, offre una protezione migliore rispetto a 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 imposta una nuova password. Il caso più complesso si verifica quando non è disponibile alcun accesso funzionante.

Tutto ciò che segue richiede la console del provider, indicata nella maggior parte dei pannelli come console VNC (virtual network computing) o console seriale. La console si collega alla macchina virtuale sotto il livello 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 /. L'ambiente di ripristino monta il filesystem root in sola lettura, quindi senza questo passaggio passwd non riesce con passwd: Authentication token manipulation error perché non può scrivere /etc/shadow.
5. Esegui passwd ubuntu per l'account interessato, quindi riavvia il server dal pannello.

Se root ha già una password e hai perso proprio quella, la shell di ripristino la richiede e questa procedura non è più utilizzabile. Avvia invece l'immagine di soccorso 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 il layout delle partizioni tramite 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

Lavora dalla sessione ancora disponibile. Se non è rimasta alcuna sessione, usa la console.

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

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

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

KbdInteractiveAuthentication yes insieme a PasswordAuthentication no consente comunque l'uso della password, perché il metodo keyboard-interactive esegue lo stesso stack PAM. Disattivare uno dei due metodi e lasciare attivo l'altro è il motivo per cui un server che sembra accettare soltanto chiavi continua ad accettare password digitate.

Too many authentication failures in un messaggio di disconnessione significa che il client ha offerto diverse chiavi prima di arrivare alla password e che il server ha raggiunto MaxAuthTries, che per impostazione predefinita vale 6. Forza un solo metodo:

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

Connection refused su una porta che funzionava fino a un minuto prima indica di solito che fail2ban che monitora SSH ha bloccato il tuo indirizzo dopo diversi tentativi falliti. La regola di ban predefinita rifiuta il pacchetto invece di scartarlo, perciò il rifiuto arriva rapidamente anziché scadere per 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 tuo.

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 qualsiasi altra impostazione. Nozioni di base sulla gestione delle chiavi SSH illustra la generazione, authorized_keys e le passphrase.

Disattiva quindi l’autenticazione tramite password e verifica la modifica con sudo sshd -T, invece di fidarti del file che hai modificato. Rafforzare la configurazione di SSH su un VPS illustra le altre impostazioni di sshd che conviene modificare, mentre I primi dieci minuti su un nuovo VPS le ordina in base alla sequenza consigliata su un server appena installato.

Dopo questa modifica, conserva comunque una password. Un server che consente soltanto l’accesso tramite chiave, ma ha una configurazione di sshd non funzionante, è raggiungibile solo 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 autorizzato a eseguire sudo e lancia 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 il sistema nel menu di ripristino di GRUB, seleziona la voce della shell root, esegui mount -o remount,rw / e quindi passwd. Se root ha già una password e hai perso proprio quella, la shell di ripristino la richiede. In tal caso devi usare l'immagine di ripristino del provider, montare il disco ed eseguire chroot.

Perché passwd visualizza "Authentication token manipulation error"?

Questo messaggio 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 è un filesystem non scrivibile. È ciò che accade nella modalità di ripristino, perché / è montato in sola lettura. Esegui mount -o remount,rw / e riprova.

Cambiare la password Linux cambia 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 esiste una sola password per account. Per questo il primo prompt sudo dopo la modifica è il test effettivo. Esegui sudo -k && sudo -v per forzare la visualizzazione del prompt mentre hai ancora una sessione funzionante.

Cambiare la password interromperà le chiavi SSH o le sessioni aperte?

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

Come posso obbligare un utente a cambiare la password al prossimo accesso?

Esegui sudo chage -d 0 deploy oppure sudo passwd -e deploy, che svolge la stessa operazione. La data dell'ultima modifica viene impostata all'epoch, PAM considera la password scaduta e il successivo accesso interattivo deve impostarne una nuova prima dell'avvio della shell. Non eseguire questa operazione su un account usato dagli script tramite SSH: in quel caso un comando non interattivo fallisce con Password change required but no TTY available. e non viene mai eseguito.