How to Change VPS Root Password for Ubuntu

How to change your VPS root password on Ubuntu

To change your VPS (virtual private server) root password for Ubuntu, open an SSH (secure shell) session as user wey fit run sudo, then run sudo passwd root. E go ask for the new password two times, and e no go ask for the old one because sudo don already confirm who you be. To change your own login password instead, run passwd without arguments. E go first ask for your current password.

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

Na the whole operation be that. Everything wey dey below na the parts wey fit cause problem: confirming say the new password dey work before you lose the session wey fit fix am, setting passwords from script, making one expire on purpose, and entering again when you don already lose the password.

Open second session before you touch password

Open second SSH session now and leave am connected. Almost every failure for this guide na two-minute fix while one authenticated shell still dey alive, and na console trip once the last one close.

Shell wey already open go continue to work after you change, lock, or expire the account wey e belong to, because SSH dey check credentials when login happen and e no check dem again. The exception na sudo. E dey check your password again through PAM (pluggable authentication modules) once the timestamp expire, 15 minutes after the last prompt by default. So the new password go get its first real test the next time sudo ask for am, no be when login happen.

Test the new password for the second session while the first one remain open.

Change your own password with passwd

passwd

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

passwd: password updated successfully na the only output wey mean say dem replace the hash for /etc/shadow. Anything else mean say the old password still dey there.

Two failures fit happen here. passwd: Authentication token manipulation error, followed by passwd: password unchanged, mean say the current password wey you type no correct, or filesystem wey dey hold /etc/shadow no fit write, as e normally dey happen for recovery mode. You must choose a longer password. come from pam_unix for /etc/pam.d/common-password, wey dey apply length and similarity checks to ordinary users.

For most VPS images, the default account (ubuntu, or any name wey your provider ship) no get password at all; na SSH key only. passwd no get current password to check, so e no fit pass the first prompt. Use sudo passwd $USER instead. E work because the image sudoers drop-in file allow that account run sudo without password.

Change another user password with sudo passwd

sudo passwd deploy

Root no dey asked for the old password, and pam_unix skip the strength checks wey e apply to ordinary users. So root fit set password wey the user no for fit set by demself.

Locking na separate action. sudo passwd -l deploy put ! before the stored hash, so no password go match am. sudo passwd -u deploy remove am. Read the state again with sudo passwd -S deploy.

Locking the password no stop that user from logging in. Any key for their ~/.ssh/authorized_keys still work, because public key authentication no dey read /etc/shadow. To stop the account completely, expire the account itself:

sudo usermod --expiredate 1 deploy

That one set the account expiry to date for 1970, so sshd go refuse the login no matter which credential dem offer. Undo am with sudo usermod --expiredate '' deploy.

Avoid passwd -d. E set empty password instead of locked password. For older release wey still get nullok inside the PAM stack, anybody fit use empty password.

Root need password for VPS?

Ubuntu dey ship with root locked. /etc/shadow dey hold ! instead of hash, and sudo passwd -S root dey print line wey start with root L. Nothing fit log in as root with password until you set one. Na why the image dey give you user wey fit use sudo instead. Make you work with least privilege user accounts for VPS instead of root. Na this pattern you suppose keep.

If you set root password, e dey give you one specific thing: way to enter through provider console. That console dey connect to virtual machine underneath network stack, so e still dey work when sshd configuration no correct or firewall rule wrong. But e get cost too. GRUB recovery menu root shell dey ask for root password when root get one. So the tool wey you go use reset forgotten password now dey behind that same password.

Setting root password no allow root log in through SSH. Ubuntu dey ship PermitRootLogin prohibit-password, meaning say na keys only. Check wetin your server actually dey use:

sudo sshd -T | grep -i permitrootlogin

sshd -T dey print the effective configuration after e resolve every Include line. So na the only honest answer once /etc/ssh/sshd_config.d/ dey contain drop-in files.

Set password from script with chpasswd

passwd dey read from terminal and you no fit control am from script. chpasswd dey read user:password pairs from standard input, one for each line.

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

This one work, but e dey put plaintext password for your shell history and your CI (continuous integration) logs. Hash am first instead:

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

openssl passwd -6 dey ask for password two times without showing wetin you type, then e print SHA-512 crypt hash wey start with $6$. -e dey tell chpasswd say the second field don already hash, so e go copy am into /etc/shadow as e be. You fit safely keep the hash for repository or CI variable, and the plaintext no ever leave the machine where you type am.

Ubuntu 24.04 dey hash new passwords with yescrypt ($y$) when passwd set dem, while openssl passwd -6 dey give you SHA-512. Both one fit verify during login, because libxcrypt dey read both formats. You fit mix dem without problem, and openssl passwd -6 dey behave the same way for every Ubuntu LTS release, but chpasswd -c YESCRYPT no dey: the older shadow package for 20.04 no know that method name. Those hashes still dey work after release upgrade, so move 24.04 server go 26.04 no force you to reset anybody password.

How you fit check whether password don change?

Start with the metadata, then prove am with a login.

sudo passwd -S deploy

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

The second field na the state: P for usable password, L for locked password, NP for no password at all. The date show when password last change, so e suppose show today. The numbers after am na the aging fields wey dey below.

The safest live test na sudo itself. sudo -k go throw away the cached timestamp, while sudo -v go force fresh prompt. If e accept the new password there, PAM don accept am, and nothing for your session change.

sudo -k && sudo -v

To test another account, run su - deploy from an unprivileged shell. No run sudo su - deploy, because root no dey ever get password prompt and the test no prove anything. Wrong password go print su: Authentication failure.

The real test na fresh SSH login from your laptop, while the working session still dey open:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). here mean say the server never offer password authentication, so no password change go let you enter. Permission denied, please try again. mean say e offer am but reject wetin you type.

Make password change happen for next login with chage

sudo chage -d 0 deploy

-d 0 dey set date of last change to epoch, so PAM go treat the password as expired. Next interactive login go ask for the current password, then ask for new one, before e give shell. sudo passwd -e deploy dey do exactly the same thing.

Use am only for accounts wey dey log in interactively with password. Expired password still dey affect key based logins, because sshd dey run PAM account stage even when na key authenticate the login. Scripted ssh deploy@203.0.113.10 'systemctl restart app' go then fail with this and stop:

Password change required but no TTY available.

Nothing after that line go run, and the job go report only non-zero exit code.

Wetin the password aging fields mean

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

Those numbers na fields 4 to 8 for that user line inside /etc/shadow. Minimum days (chage -m) na how long the user must wait before changing am again. This stops person from changing straight back to the old password after forced change. Maximum days (chage -M) na how long the password go remain valid. Warning days (chage -W) na when login go start showing warning. Inactive days (chage -I) na the grace period after expiry before the password no go dey accepted again at all. Account expiry (chage -E) na a fixed date, and e no depend on the password.

sudo chage -M 90 -W 14 deploy

Set this only when policy require am. NIST (the US National Institute of Standards and Technology) don advise since 2017 against routine password expiry, because e dey push people to use predictable variations of one password. E recommend forcing a change when there be evidence say the account don get compromised. One long, unique password wey dey inside password manager, plus key based SSH, better pass 90 day cycle.

Wetín to do when you don lose the root password

If any account for the server fit run sudo, nothing dey to recover: sudo passwd root go set new one. The difficult case na when no working login dey at all.

Everything below need the provider console. For most panels, dem list am as VNC (virtual network computing) or serial console. E dey connect to the virtual machine underneath the network stack, so sshd settings and firewall rules no affect am.

1. Reboot the server from the panel and monitor the console.
2. Open the GRUB menu. Cloud images usually set GRUB_TIMEOUT=0, so hold Shift for BIOS boot, or press Esc repeatedly for UEFI boot, as soon as reboot start.
3. Choose Advanced options for Ubuntu, then the entry wey end with (recovery mode), then root for the recovery menu.
4. Run mount -o remount,rw / first. Recovery mounts the root filesystem as read-only, so without this, passwd go fail with passwd: Authentication token manipulation error because e no fit write /etc/shadow.
5. Run passwd ubuntu for the account wey you need, then reboot from the panel.

If root already get password and na that password you lose, the recovery shell go ask for am and you no fit use that route. Boot the provider rescue image instead, then mount the real disk and change the password inside am.

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

Read the partition layout from lsblk instead of copying /dev/vda1 from this page. The root partition na the big one. For UEFI image, e dey beside small EFI partition wey no get any /etc directory at all.

Wetin to do when SSH stop accepting your password

Work from the session wey you still get. If no session remain, use the console.

Permission denied, please try again. mean say the server offer password authentication but reject wetin you send. The common causes na caps lock, or console keyboard layout wey different from the one wey you use when you set the password.

Permission denied (publickey). mean say the server never offer password authentication. PasswordAuthentication no dey set somewhere, and for Ubuntu 22.04 and later e usually dey inside drop-in file under /etc/ssh/sshd_config.d/ wey override the main file. Read the effective values:

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

KbdInteractiveAuthentication yes together with PasswordAuthentication no still allow password enter, because the keyboard-interactive method dey run the same PAM stack. If you turn off one and leave the other on, server wey look like say na key-only still go accept passwords wey person type.

That same line na wetin rejected key login dey print too. So if na key instead of password wey you offer, the server password setting na only one of the five faults behind Permission denied (publickey). The ssh -v output go tell you which one you get.

Too many authentication failures for disconnect message mean say your client offer several keys before e reach password, and the server hit MaxAuthTries, wey be 6 by default. Force one method:

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

Connection refused for port wey work one minute ago usually mean say fail2ban dey monitor SSH don ban your address after repeated failures. Its default ban rule dey reject the packet instead of dropping am. Na why the refusal dey return fast instead of timing out. From the console, sudo fail2ban-client status sshd go list the banned addresses, and sudo fail2ban-client set sshd unbanip 203.0.113.10 go clear your own.

Password na stepping stone; keys na the final state

Any password wey fit work over SSH na password wey every scanner for internet fit guess. Move go key based authentication, and guessing no go matter again. Generate key pair, install the public half, then confirm say the key fit log you in from another terminal before you change anything else. SSH key management basics cover key generation, authorized_keys and passphrases.

After that, turn off password authentication, then confirm am with sudo sshd -T instead of trusting the file wey you edit. hardening SSH on a VPS go through the remaining sshd settings wey make sense to change, while the first ten minutes on a new VPS arrange dem in the order to apply dem for fresh server.

Keep one password after that. If key-only server get broken sshd config, you fit reach am only through provider console, and that console go ask for username and password. An account with strong password wey you don store na wetin separate five-minute fix from reinstall.

FAQ

How I fit change root password for my VPS if I no sabi the old one?

Log in as user wey fit run sudo, then run sudo passwd root. E go set new password without asking for the old one, because sudo don already authenticate you. If no account for the server fit run sudo, open the provider console, reboot enter the GRUB recovery menu, choose the root shell entry, run mount -o remount,rw /, then run passwd. If root already get password and na that one you lose, the recovery shell go ask for am. The remaining option na the provider rescue image, with the disk mounted and chrooted.

Why passwd dey show "Authentication token manipulation error"?

Two things fit cause that message. The common one na wrong answer for the Current password: prompt, and the passwd: password unchanged line under am confirm say nothing write. The other one na filesystem wey no fit write to. Na this one you go meet for recovery mode, because / dey mounted read-only there. Run mount -o remount,rw / and try again.

If I change my Linux password, e go also change my sudo password?

Yes. sudo no get password of its own. E dey authenticate you through PAM against the same /etc/shadow entry wey SSH and su dey use, so each account get one password. Na why the first sudo prompt after you change am na the real test. Run sudo -k && sudo -v to force that prompt while your session still dey work.

If I change my password, my SSH keys or open sessions go stop working?

No. Public key authentication no ever read /etc/shadow, so keys go continue to work after password change, after passwd -l, and after chage -d 0. Sessions wey already open go remain open, because SSH dey check credentials only when login happen. The only thing wey change inside live session na sudo. E go ask for the new password once the 15 minute timestamp expire.

How I fit force user to change password for the next login?

Run sudo chage -d 0 deploy, or sudo passwd -e deploy, wey dey do the same thing. The stored last-change date go move to the epoch, PAM go treat the password as expired, and the next interactive login must set new one before shell start. No do this for account wey scripts dey use over SSH. A non-interactive command go then fail with Password change required but no TTY available. and e no go run.