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 another SSH session now and leave am connected. Almost every failure for this guide na two-minute fix while one authenticated shell still dey alive, but e go require console trip once the last one close.

Shell wey don 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 cached credentials expire, after 15 minutes by default for Ubuntu. That window no dey count from the last prompt, because sudo -v dey refresh the cached credentials without asking again. So the new password get its first real test the next time sudo actually ask for am, no be when login happen.

Test the new password for the second session while the first one still dey 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 need provide the old password, and pam_unix no dey apply the strength checks wey e apply to ordinary users. So root fit set password wey the user no for fit set by themselves.

Locking na separate action. sudo passwd -l deploy puts ! before the stored hash, so no password fit match am. sudo passwd -u deploy removes 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 dey work, because public key authentication no check the password hash. To stop the account completely, expire the account itself:

sudo usermod --expiredate 1 deploy

This sets the account expiry to a date for 1970, so sshd go refuse the login no matter the credential wey dem offer. Undo am with sudo usermod --expiredate '' deploy.

Avoid passwd -d. E sets an empty password instead of locked password. For older release wey still get nullok for the PAM stack, anybody fit use an 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, so script no fit control am. chpasswd dey read user:password pairs from standard input, one pair for each line.

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

This one work, but e go 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 go ask for password two times without showing wetin you type, then print SHA-512 crypt hash wey start with $6$. -e tells 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 comot from the machine where you type am.

Ubuntu 24.04 dey hash new passwords with yescrypt ($y$) when passwd set dem, while openssl passwd -6 gives you SHA-512. Both ones dey verify during login, because libxcrypt fit read both formats. You fit mix dem without problem, and openssl passwd -6 dey behave the same way for every Ubuntu LTS release from 18.04 reach, but chpasswd -c YESCRYPT no dey: the older shadow package for 20.04 no know that method name. Ubuntu 16.04 na the exception, because its OpenSSL 1.0.2 no get -6 option at all. Those hashes still work after release upgrade, so moving 24.04 server go 26.04 no force you 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 the next login with chage

sudo chage -d 0 deploy

-d 0 dey set the date of the last change to the epoch, so PAM go treat the password as expired. The next interactive login go ask for the current password, then ask for a new one, before e give out a 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 dey affect key-based logins too, because sshd dey run the PAM account stage even when na key authenticate the login. Scripted ssh deploy@203.0.113.10 'systemctl restart app' go fail with this before the command run:

Password change required but no TTY available.

The remote command no go run and ssh go exit with a non-zero code. Unless the calling script stop when error happen, with set -e or an explicit check, the lines after am go still run and the job fit finish as if the restart don happen.

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 you use when you set the password.

Permission denied (publickey). mean say the server never offer password authentication, so the effective value na PasswordAuthentication no. That no fit dey inside the main file or one drop-in, so check both. sshd dey read the files under /etc/ssh/sshd_config.d/ when e start to process im configuration, and e keep the first value e find for each keyword, so one drop-in dey override /etc/ssh/sshd_config. The same rule often work the other way for Ubuntu 24.04 servers wey dem install from the ISO with SSH enabled: the installer dey leave one cloud-init drop-in, 50-cloud-init.conf, wey set PasswordAuthentication yes, so any no wey you add to the main file go ignore. 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 fit still accept password wey person type.

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

Too many authentication failures for disconnect message mean say the connection don use the server MaxAuthTries allowance finish, wey be 6 attempts by default. The common cause na client wey offer several keys before e reach password. 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 watch SSH and e ban your address after repeated failures. Its default ban rule dey reject the packet instead of dropping am, na why the refusal dey come back 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 with 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 provider console, reboot enter 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 to use provider rescue image, mount the disk, then chroot enter am.

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 accept writes. Na this one dey happen for recovery mode, because / dey mounted read-only there. Run mount -o remount,rw / and try again.

Changing my Linux password 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 be the real test. Run sudo -k && sudo -v to force that prompt while your current session still dey work.

Changing my password go spoil my SSH keys or sessions wey I don open?

Password change or passwd -l no dey cause that. Public key authentication no check password hash, so keys go continue to work after either one. chage -d 0 different: sshd still run PAM account checks after key login. Those checks read password aging fields for /etc/shadow. So, expired password fit make key login ask for new password and make scripted SSH commands fail. 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 use 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.