How I fit Change VPS Root Password for Ubuntu

How to change your VPS root password on Ubuntu

To change your VPS (virtual private server) root password on Ubuntu, open one 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 say na you. If you wan 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 so the whole operation be. Everything wey dey below na the part wey fit get problem: confirm say the new password dey work before you lose the session wey fit fix am, set passwords from script, expire one password on purpose, and enter again when you don lose the password.

Open second session before yu 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, but e go need 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 for login and e no dey 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 im first real test the next time sudo ask for am, no be for login.

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 the hash for /etc/shadow don replace. Any other output 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 the filesystem wey hold /etc/shadow no fit write, and na the normal state for recovery mode. You must choose a longer password. dey 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; e only get SSH key. passwd no get current password to check, so e no fit pass the first prompt. Use sudo passwd $USER instead. E dey work because the image's sudoers drop-in file allow that account run sudo without password.

Change another user's password with sudo passwd

sudo passwd deploy

Root no dey asked for the old password, and pam_unix dey skip the strength checks wey e applies to ordinary users, so root fit set a password wey the user no for fit set by themselves.

Locking na separate action. sudo passwd -l deploy dey put a ! for front of the stored hash, so no password go match am. sudo passwd -u deploy dey remove am. Read the state back with sudo passwd -S deploy.

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

sudo usermod --expiredate 1 deploy

That one dey set the account expiry to a 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 dey set an empty password instead of locked one, and for an older release wey still get nullok inside the PAM stack, an empty password na one wey anybody fit use.

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. Nobody fit log in as root with password until you set one. Na why the image dey give you user wey get sudo permission instead. Use least privilege user accounts for VPS instead of root. Na this pattern you suppose maintain.

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 under network stack, so e still dey work when sshd configuration no correct or firewall rule dey 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 protected by that same password.

Setting root password no mean say root fit log in through SSH. Ubuntu dey ship PermitRootLogin prohibit-password, wey mean say na keys only. Check wetin your server really dey use:

sudo sshd -T | grep -i permitrootlogin

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

Set password from script with chpasswd

passwd dey read from terminal and e no fit run 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 dey 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 anything, then e print SHA-512 crypt hash wey start with $6$. -e tell chpasswd say the second field don already hash, so e copy am enter /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, but openssl passwd -6 dey give you SHA-512. Both ones dey verify for 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, but chpasswd -c YESCRYPT no be so: the older shadow package for 20.04 no know that method name.

Password change actually work say how you go check am?

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

sudo passwd -S deploy

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

The second field na the state: P mean password dey usable, L mean e lock, NP mean no password dey at all. The date na when dem last change the password, 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 throws away the cached timestamp, and sudo -v forces 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 dem no dey ask for password 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 the server never offer password authentication, so no password change go let you enter. Permission denied, please try again. mean e offer am but reject wetin you type.

Force password change for next login with chage

sudo chage -d 0 deploy

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

Password change required but no TTY available.

Nothing after that line go run, and the job go report only a 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 e fit change am again. E dey stop person from immediately going 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 to print warning. Inactive days (chage -I) na the grace period after expiry before the password stop to dey accepted completely. Account expiry (chage -E) na a fixed date, and e no depend on the password.

sudo chage -M 90 -W 14 deploy

Set am 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 toward predictable variations of one password. E recommend say make system force change when evidence show say compromise don happen. One long, unique password wey dey inside password manager, plus key based SSH, better pass 90 day cycle.

Wetin to do when you don lose the root password

If any account for the box fit run sudo, you no get anything to recover: sudo passwd root go set new one. The hard case na when no login dey work at all.

Everything below need the provider console, wey most panels list as VNC (virtual network computing) or serial console. E dey connect directly to the virtual machine under 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 during a BIOS boot, or press Esc repeatedly during a UEFI boot, as soon as the 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 if you no run 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 a password and na the one wey you lose, that recovery shell go ask for am and you no fit continue with this method. Boot the provider's 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 a UEFI image, e dey beside a 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 usual 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 one 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 through, 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 passwords wey person type.

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

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 wey dey monitor SSH ban your address after repeated failures. Its default ban rule reject the packet instead of dropping am, na why the refusal return fast instead of timing out. From the console, sudo fail2ban-client status sshd list the banned addresses and sudo fail2ban-client set sshd unbanip 203.0.113.10 clear your own.

Password na stepping stone, keys na the end state

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

Then turn password authentication off, and 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 dey worth changing, and the first ten minutes on a new VPS arrange dem for the order wey you suppose do dem on fresh server.

Keep one password after that. Server wey dey use key only and get broken sshd config fit only reach through provider console, and that console go ask for username and password. Account wey get 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 authenticate you already. If no account for the box 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 don already get password and na that one you lose, the recovery shell go ask for am. The remaining option na to use the 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 write, and na this one you go hit 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 e 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 also why the first sudo prompt after change na the real test. Run sudo -k && sudo -v to force that prompt while your session still dey work.

Changing my password go break my SSH keys or sessions wey dey open?

No. Public key authentication no dey read /etc/shadow, so keys go still work after password change, after passwd -l, and after chage -d 0. Sessions wey don already open go remain open, because SSH dey check credentials only when login happen. The only thing wey change inside live session na sudo, wey 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 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: non-interactive command go then fail with Password change required but no TTY available. and e no go run.