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.

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 finché una shell autenticata resta attiva; quando si chiude anche l’ultima, invece, è necessario accedere alla console.

Una shell già aperta continua a funzionare 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. Questo componente verifica nuovamente la password tramite PAM (moduli di autenticazione collegabili) quando le credenziali memorizzate nella cache scadono, dopo 15 minuti per impostazione predefinita su Ubuntu. Questo intervallo non decorre dall’ultimo prompt, perché sudo -v aggiorna le credenziali memorizzate nella cache senza richiederle nuovamente. La nuova password viene quindi 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 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.

Cambiare 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. Root può quindi impostare una password che l’utente non avrebbe potuto impostare autonomamente.

Il blocco della password è un’operazione distinta. sudo passwd -l deploy antepone un ! all’hash memorizzato, quindi nessuna password può corrispondervi. 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 con chiave pubblica non verifica l’hash della password. Per disabilitare completamente un account, fare scadere l’account:

sudo usermod --expiredate 1 deploy

In questo modo la scadenza dell’account viene impostata su una data del 1970 e sshd rifiuta il login indipendentemente dalla credenziale utilizzata. Annullare l’operazione con sudo usermod --expiredate '' deploy.

Evitare passwd -d. Imposta una password vuota anziché bloccarla e, nelle versioni precedenti che includono ancora nullok nello stack PAM, una password vuota può essere utilizzata 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

Il comando funziona, ma inserisce una password in chiaro nella cronologia della shell e nei log della CI (integrazione continua). 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 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 CI, mentre la password in chiaro non lascia mai il computer su cui è stata digitata.

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 durante l'accesso, perché libxcrypt legge entrambi. È possibile utilizzarli insieme senza problemi e openssl passwd -6 si comporta allo stesso modo in ogni release Ubuntu LTS dalla 18.04 in poi; lo stesso non vale per chpasswd -c YESCRYPT: il pacchetto shadow meno recente di 20.04 non riconosce quel nome di metodo. Ubuntu 16.04 è un'eccezione, perché OpenSSL 1.0.2 non dispone proprio dell'opzione -6. Questi hash restano validi anche dopo il passaggio a una release successiva, quindi aggiornare 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.

Forza 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 e poi una nuova password, prima di concedere una shell. sudo passwd -e deploy esegue esattamente la stessa operazione.

Usalo solo per gli account che effettuano il login interattivamente 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 effettuata con una chiave. Un ssh deploy@203.0.113.10 'systemctl restart app' eseguito da uno script ha quindi esito negativo con questo messaggio, prima dell’esecuzione del comando:

Password change required but no TTY available.

Il comando remoto non viene mai eseguito e ssh termina con un codice diverso da zero. Se lo script chiamante non si interrompe in caso di errore, usando set -e o un controllo esplicito, le righe successive vengono comunque eseguite e il job può terminare come se il riavvio fosse avvenuto.

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 attiva. Se non hai più sessioni, usa la console.

Permission denied, please try again. indica che il server ha offerto l'autenticazione tramite password e ha rifiutato il valore inviato. Le cause più comuni sono Caps Lock 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, quindi il valore effettivo è PasswordAuthentication no. Questa no può trovarsi nel file principale o in un drop-in, quindi controlla entrambi. All'avvio della configurazione, sshd legge i file sotto /etc/ssh/sshd_config.d/ e mantiene il primo valore trovato per ogni parola chiave; di conseguenza, un drop-in sovrascrive /etc/ssh/sshd_config. Sui server Ubuntu 24.04 installati dall'immagine ISO con SSH abilitato spesso vale anche la regola opposta: l'installer lascia il drop-in di cloud-init 50-cloud-init.conf, che imposta PasswordAuthentication yes, e un no aggiunto al file principale viene quindi ignorato. 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 esegue lo stesso stack PAM. Disattivare uno dei due metodi e lasciare attivo l'altro è il motivo per cui un server apparentemente configurato per usare solo le chiavi continua ad accettare password digitate.

La stessa riga viene visualizzata anche quando viene rifiutato un accesso con chiave. Quindi, se stavi offrendo una chiave invece di una password, l'impostazione della password del server è soltanto uno dei cinque problemi alla base di Permission denied (publickey), e l'output di ssh -v indica quale si è verificato.

Too many authentication failures in un messaggio di disconnessione indica che la connessione ha esaurito la disponibilità MaxAuthTries del server, pari a 6 tentativi per impostazione predefinita. La causa più comune è un client che ha offerto diverse chiavi prima di arrivare alla password. 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 generalmente 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 anziché 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 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 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 cambio la password di root sul mio VPS se non conosco quella precedente?

Accedi con un utente autorizzato a eseguire sudo ed esegui sudo passwd root. Imposta una nuova password senza chiedere 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 questo caso, l'unica alternativa è usare l'immagine di ripristino del provider, montare il disco ed eseguire chroot.

Perché passwd restituisce "Authentication token manipulation error"?

Questo messaggio può avere due cause. La più comune è una risposta errata alla richiesta Current password:; la riga passwd: password unchanged sottostante conferma che non è stato scritto nulla. L'altra è un filesystem non scrivibile. È ciò che accade in modalità di ripristino, perché / è montato in sola lettura. Esegui mount -o remount,rw / e riprova.

Cambiare la password Linux cambia anche la password 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 la prima richiesta sudo dopo una modifica costituisce il test effettivo. Esegui sudo -k && sudo -v per forzare quella richiesta mentre hai ancora una sessione funzionante.

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

No, né una modifica della password né passwd -l hanno questo effetto. L'autenticazione con chiave pubblica non verifica l'hash della password, quindi le chiavi continuano a funzionare dopo entrambe le operazioni. chage -d 0 è diverso: sshd esegue comunque i controlli dell'account PAM dopo un accesso con chiave e questi leggono i dati relativi alla scadenza della password in /etc/shadow. Di conseguenza, una password scaduta fa sì che un accesso con chiave richieda una nuova password e fa fallire i comandi SSH eseguiti tramite script. 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 relativo timestamp di 15 minuti.

Come obbligo un utente a cambiare la password al successivo accesso?

Esegui sudo chage -d 0 deploy oppure sudo passwd -e deploy, che producono lo stesso risultato. La data dell'ultima modifica memorizzata 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 utilizzato dagli script tramite SSH: in seguito un comando non interattivo fallisce con Password change required but no TTY available. e non viene mai eseguito.