Come cambiare la password root su un VPS Ubuntu

Come cambiare la password di root del VPS su Ubuntu

Per cambiare la password di 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 cambiare invece la password del tuo account, 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. Il resto della guida tratta i casi che causano problemi: verificare che la nuova password funzioni prima di perdere la sessione necessaria per correggere l’errore, impostare password da uno script, far scadere intenzionalmente una password e recuperare l’accesso quando la password è già stata persa.

Aprire una seconda sessione prima di modificare una password

Aprire ora una seconda sessione SSH e lasciarla connessa. Quasi tutti gli errori descritti in questa guida si risolvono in due minuti se 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 la modifica, il blocco o la scadenza dell'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 (pluggable authentication modules). Per impostazione predefinita, ciò avviene 15 minuti dopo l'ultima richiesta. La nuova password viene quindi verificata realmente la prima volta che sudo la richiede, non durante il login.

Verificare 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 output lascia invariata la password precedente.

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, 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 ordinari.

Nella maggior parte delle immagini VPS, l'account predefinito (ubuntu o il nome con cui viene fornito dal provider) non ha alcuna password, ma solo una chiave SSH. passwd non ha una password corrente da verificare e 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. Di conseguenza, root può impostare una password che l'utente non avrebbe potuto impostare autonomamente.

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

Il blocco della password non impedisce all'utente di effettuare il login. Qualsiasi chiave presente nel suo ~/.ssh/authorized_keys continua a funzionare, perché l'autenticazione a chiave pubblica non legge /etc/shadow. Per disabilitare completamente un account, farlo scadere:

sudo usermod --expiredate 1 deploy

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

Evitare passwd -d. Imposta una password vuota invece di bloccare l'account. In una release precedente che include ancora nullok nello stack PAM, una password vuota può essere usata da chiunque.

Serve una password per root su un VPS?

Ubuntu viene distribuito con 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 con una password finché non ne imposti una. Per questo l'immagine fornisce invece un utente abilitato all'uso di sudo. È consigliabile operare tramite account utente con privilegi minimi su un VPS, non come root.

Impostare una password per root offre un vantaggio specifico: 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. Tuttavia, comporta anche un costo. La shell root del menu di ripristino di GRUB richiede la password di root quando ne è impostata 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 tramite sole chiavi. Verifica quale configurazione utilizza 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). Calcola prima l'hash:

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

openssl passwd -6 richiede la password due volte senza visualizzarla, quindi stampa un hash SHA-512 crypt che inizia con $6$. -e indica a chpasswd che il secondo campo contiene già un hash, quindi lo copia in /etc/shadow senza modificarlo. L'hash può essere archiviato in sicurezza in un repository o in una variabile CI; la password in chiaro non lascia mai il computer sul quale è stata digitata.

Ubuntu 24.04 calcola l'hash 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. Anche questi hash restano validi dopo l'aggiornamento a una nuova release, quindi portare un server 24.04 a 26.04 non obbliga a reimpostare le password degli utenti.

Come verificare che la password sia stata effettivamente modificata?

Iniziare dai metadati, quindi verificare 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 per l'assenza completa di una password. La data indica l'ultima modifica della password, quindi dovrebbe corrispondere a oggi. I numeri successivi sono i parametri di scadenza descritti di seguito.

Il test operativo 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 convalidata e la sessione non è stata modificata.

sudo -k && sudo -v

Per verificare un altro account, eseguire su - deploy da una shell senza privilegi. Non eseguire sudo su - deploy, perché root non deve mai inserire una password e il test non dimostrerebbe 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

Permission denied (publickey). in questo caso 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 inserito.

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 prossimo accesso interattivo viene richiesta la password corrente, quindi una nuova password, prima di fornire una shell. sudo passwd -e deploy produce esattamente lo stesso risultato.

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

Password change required but no TTY available.

Nessuna istruzione successiva a quella riga viene eseguita 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 tornare subito alla password precedente dopo una modifica obbligatoria. I giorni massimi (chage -M) indicano per quanto tempo la password rimane 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 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 è richiesto da una policy. Dal 2017 il NIST (il National Institute of Standards and Technology degli Stati Uniti) sconsiglia la scadenza periodica delle password. Questa pratica spinge gli utenti a usare variazioni prevedibili della stessa password. Il NIST raccomanda invece di obbligare alla modifica quando vi sono prove di una compromissione. Una password lunga e univoca conservata in un password manager, insieme a SSH basato su chiavi, offre una sicurezza maggiore rispetto a un ciclo di 90 giorni.

Cosa fare quando si perde 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 si verifica quando non è disponibile alcun accesso funzionante.

Per tutte le operazioni seguenti è necessaria 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 lo stack di rete, quindi le impostazioni di sshd e le regole del firewall non la influenzano.

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

Se root ha già una password e quella persa è proprio questa, la shell di ripristino la richiede e questa procedura non è più utilizzabile. Avviare invece l'immagine di ripristino del provider, montare il disco reale e modificare 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

Leggere il layout 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

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

Permission denied, please try again. indica che il server ha offerto l'autenticazione tramite password, ma ha rifiutato i dati inviati. 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). indica che il server non ha mai offerto l'autenticazione tramite password. PasswordAuthentication no è impostato da qualche parte e, in Ubuntu 22.04 e versioni successive, di solito si trova 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 di usare una password, perché il metodo keyboard-interactive utilizza lo stesso stack PAM. Disattivare uno dei due metodi e lasciare attivo l'altro è il modo in cui un server apparentemente configurato per accettare solo chiavi continua ad accettare password digitate.

La stessa riga viene mostrata anche quando un accesso tramite chiave viene rifiutato. Pertanto, se stavi offrendo una chiave invece di una password, l'impostazione della password del server è soltanto una delle cinque cause di Permission denied (publickey), e l'output di ssh -v indica quale si applica.

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. 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 sta monitorando SSH e ha bloccato il tuo indirizzo dopo diversi tentativi falliti. La regola di blocco predefinita rifiuta il pacchetto invece di scartarlo; per questo il rifiuto arriva rapidamente invece di andare in 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 blocco dal tuo indirizzo.

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 chiave 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 tratta la generazione, authorized_keys e le passphrase.

Disabilita quindi l’autenticazione tramite password e verifica la modifica con sudo sshd -T, senza limitarti a considerare attendibile il file che hai modificato. mettere in sicurezza SSH su un VPS illustra le altre impostazioni di sshd che conviene modificare, mentre i primi dieci minuti su un nuovo VPS le presenta nell’ordine da seguire su un server appena installato.

Conserva comunque una password. Un server che consente soltanto l’accesso tramite chiave, ma ha una configurazione 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 modo sicuro può fare la differenza tra una correzione di cinque minuti e una reinstallazione.

FAQ

Come posso modificare 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 chiedere quella precedente, perché sudo ha già eseguito l'autenticazione. 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 /, quindi esegui passwd. Se root ha già una password e hai perso proprio quella, la shell di ripristino la richiede. In tal caso, l'unica alternativa è usare l'immagine di rescue del provider, montare il disco ed eseguire chroot.

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

La modifica della password Linux modifica anche la password sudo?

Sì. sudo non ha una password propria. Esegue l'autenticazione tramite PAM usando la stessa voce /etc/shadow utilizzata da SSH e su. Esiste quindi una sola password per account. 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. Le chiavi continuano quindi 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 modificare la password al login successivo?

Esegui sudo chage -d 0 deploy oppure sudo passwd -e deploy, che produce lo stesso risultato. La data dell'ultima modifica memorizzata viene impostata all'epoch. PAM considera quindi la password scaduta e il login interattivo successivo deve impostarne una nuova prima di avviare una shell. Non applicare questa procedura a un account usato dagli script tramite SSH: un comando non interattivo fallisce con Password change required but no TTY available. e non viene mai eseguito.