Change your VPS root password on Ubuntu

How to change your VPS root password on Ubuntu

To change your VPS (virtual private server) root password on Ubuntu, open an SSH (secure shell) session as a user who can run sudo, then run sudo passwd root. It asks for the new password twice and never asks for the old one, because sudo has already proved who you are. To change your own login password instead, run passwd with no arguments, and it asks for your current password first.

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

That is the whole operation. Everything below is the part that goes wrong: proving the new password works before you lose the session that could fix it, setting passwords from a script, expiring one on purpose, and getting back in when the password is already lost.

Open a second session before you touch a password

Open a second SSH session now and leave it connected. Almost every failure in this guide is a two minute fix while one authenticated shell is still alive, and a console trip once the last one closes.

A shell that is already open keeps working after you change, lock or expire the account it belongs to, because SSH checks credentials at login and does not check them again. The exception is sudo. It re-checks your password through PAM (pluggable authentication modules) once its timestamp expires, 15 minutes after the last prompt by default. So the new password gets its first real test the next time sudo asks for it, not at login.

Test the new password in the second session while the first one stays 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 is the only output that means the hash in /etc/shadow was replaced. Anything else left the old password in place.

Two failures happen here. passwd: Authentication token manipulation error, followed by passwd: password unchanged, means the current password you typed was wrong, or the filesystem holding /etc/shadow cannot be written, which is the normal state in recovery mode. You must choose a longer password. comes from pam_unix in /etc/pam.d/common-password, which applies length and similarity checks to ordinary users.

On most VPS images the default account (ubuntu, or whatever name your provider ships) has no password at all, only an SSH key. passwd has no current password to check against, so it cannot get past the first prompt. Use sudo passwd $USER instead, which works because the image's sudoers drop-in file lets that account run sudo without a password.

Change another user's password with sudo passwd

sudo passwd deploy

Root is not asked for the old password, and pam_unix skips the strength checks it applies to ordinary users, so root can set a password that the user could not have set for themselves.

Locking is a separate action. sudo passwd -l deploy puts a ! in front of the stored hash, so no password matches it. sudo passwd -u deploy removes it. Read the state back with sudo passwd -S deploy.

Locking the password does not stop that user logging in. Any key in their ~/.ssh/authorized_keys still works, because public key authentication never reads /etc/shadow. To stop an account completely, expire the account itself:

sudo usermod --expiredate 1 deploy

That sets the account expiry to a date in 1970, so sshd refuses the login whatever credential is offered. Undo it with sudo usermod --expiredate '' deploy.

Avoid passwd -d. It sets an empty password rather than a locked one, and on an older release that still carries nullok in the PAM stack, an empty password is one anybody can use.

Does root need a password on a VPS?

Ubuntu ships with root locked. /etc/shadow holds ! in place of a hash, and sudo passwd -S root prints a line starting root L. Nothing can log in as root with a password until you set one, which is why the image hands you a sudo capable user instead. Working through least privilege user accounts on a VPS rather than as root is the pattern to keep.

Setting a root password buys one specific thing: a way in through the provider console. That console attaches to the virtual machine underneath the network stack, so it keeps working when sshd is misconfigured or a firewall rule is wrong. It costs you something too. The GRUB recovery menu's root shell asks for the root password when root has one, so the tool you would use to reset a forgotten password now sits behind that same password.

Setting a root password does not let root log in over SSH. Ubuntu ships PermitRootLogin prohibit-password, which means keys only. Check what your server actually uses:

sudo sshd -T | grep -i permitrootlogin

sshd -T prints the effective configuration after every Include line is resolved, so it is the only honest answer once /etc/ssh/sshd_config.d/ holds drop-in files.

Set a password from a script with chpasswd

passwd reads from the terminal and cannot be driven from a script. chpasswd reads user:password pairs on standard input, one per line.

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

That works, and it puts a plaintext password into your shell history and your CI (continuous integration) logs. Hash it first instead:

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

openssl passwd -6 prompts for the password twice with no echo, then prints a SHA-512 crypt hash starting with $6$. -e tells chpasswd that the second field is already hashed, so it is copied into /etc/shadow as it stands. The hash is safe to keep in a repository or a CI variable, and the plaintext never leaves the machine where you typed it.

Ubuntu 24.04 hashes new passwords with yescrypt ($y$) when passwd sets them, while openssl passwd -6 gives you SHA-512. Both verify at login, because libxcrypt reads both formats. Mixing them is fine, and openssl passwd -6 behaves the same way on every Ubuntu LTS release, which chpasswd -c YESCRYPT does not: the older shadow package on 20.04 does not know that method name.

How do you check the password actually changed?

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

sudo passwd -S deploy

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

The second field is the state: P for a usable password, L for locked, NP for no password at all. The date is when the password last changed, so it should read today. The numbers after it are the aging fields covered below.

The safest live test is sudo itself. sudo -k throws away the cached timestamp and sudo -v forces a fresh prompt. If the new password is accepted there, PAM accepted it, and nothing about your session changed.

sudo -k && sudo -v

To test another account, run su - deploy from an unprivileged shell. Do not run sudo su - deploy, because root is never asked for a password and the test proves nothing. A wrong password prints su: Authentication failure.

The real test is a fresh SSH login from your laptop, with the working session still open:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). here means the server never offered password authentication, so no password change will get you in. Permission denied, please try again. means it did offer it and rejected what you typed.

Force a password change at the next login with chage

sudo chage -d 0 deploy

-d 0 sets the date of last change to the epoch, so PAM treats the password as expired. The next interactive login asks for the current password, then for a new one, before it gives out a shell. sudo passwd -e deploy does exactly the same thing.

Use it only for accounts that log in interactively with a password. An expired password also affects key based logins, because sshd runs the PAM account stage even when a key did the authenticating. A scripted ssh deploy@203.0.113.10 'systemctl restart app' then fails with this and stops:

Password change required but no TTY available.

Nothing after that line runs, and the job reports only a non-zero exit code.

What 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 are fields 4 to 8 of that user's line in /etc/shadow. Minimum days (chage -m) is how long the user must wait before changing again, which stops someone cycling straight back to the old password after a forced change. Maximum days (chage -M) is how long the password stays valid. Warning days (chage -W) is when logins start printing a warning. Inactive days (chage -I) is the grace period after expiry before the password stops being accepted at all. Account expiry (chage -E) is a hard date, and it is independent of the password.

sudo chage -M 90 -W 14 deploy

Set that only when a policy requires it. NIST (the US National Institute of Standards and Technology) has advised since 2017 against routine password expiry, because it pushes people toward predictable variations of one password, and recommends forcing a change when there is evidence of compromise. A long unique password held in a password manager, plus key based SSH, beats a 90 day cycle.

What to do when you have lost the root password

If any account on the box can run sudo, there is nothing to recover: sudo passwd root sets a new one. The hard case is no working login at all.

Everything below needs the provider console, listed in most panels as a VNC (virtual network computing) or serial console. It attaches to the virtual machine underneath the network stack, so sshd settings and firewall rules do not affect it.

1. Reboot the server from the panel and watch the console.
2. Get the GRUB menu. Cloud images usually set GRUB_TIMEOUT=0, so hold Shift on a BIOS boot, or press Esc repeatedly on a UEFI boot, as soon as the reboot starts.
3. Choose Advanced options for Ubuntu, then the entry ending in (recovery mode), then root in the recovery menu.
4. Run mount -o remount,rw / first. Recovery mounts the root filesystem read-only, so without this passwd fails with passwd: Authentication token manipulation error because it cannot write /etc/shadow.
5. Run passwd ubuntu for the account you need, then reboot from the panel.

If root already has a password and it is the one you lost, that recovery shell asks for it and the route is closed. Boot the provider's rescue image instead, then mount the real disk and change the password inside it.

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 rather than copying /dev/vda1 from this page. The root partition is the large one. On a UEFI image it sits beside a small EFI partition that holds no /etc directory at all.

What to do when SSH stops accepting your password

Work from the session you still have. If no session is left, use the console.

Permission denied, please try again. means the server offered password authentication and rejected what you sent. The usual causes are caps lock, or a console keyboard layout that differs from the one you used when you set the password.

Permission denied (publickey). means the server never offered password authentication. PasswordAuthentication no is set somewhere, and on Ubuntu 22.04 and later it usually lives in a drop-in file under /etc/ssh/sshd_config.d/ that overrides the main file. Read the effective values:

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

KbdInteractiveAuthentication yes alongside PasswordAuthentication no still lets a password through, because the keyboard-interactive method runs the same PAM stack. Turning off one and leaving the other on is how a server that looks key-only keeps accepting typed passwords.

Too many authentication failures in a disconnect message means your client offered several keys before it reached the password, and the server hit MaxAuthTries, which is 6 by default. Force a single method:

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

Connection refused on a port that worked a minute ago usually means fail2ban watching SSH banned your address after repeated failures. Its default ban rule rejects the packet instead of dropping it, which is why the refusal comes back fast rather than timing out. From the console, sudo fail2ban-client status sshd lists the banned addresses and sudo fail2ban-client set sshd unbanip 203.0.113.10 clears yours.

Passwords are a stepping stone, keys are the end state

A password that works over SSH is a password every scanner on the internet gets to guess. Move to key based authentication and the guessing stops mattering. Generate a key pair, install the public half, and confirm the key logs you in from a second terminal before you change anything else. SSH key management basics covers generation, authorized_keys and passphrases.

Then turn password authentication off, and confirm it with sudo sshd -T rather than trusting the file you edited. hardening SSH on a VPS works through the rest of the sshd settings worth changing, and the first ten minutes on a new VPS puts them in the order to do them on a fresh server.

Keep one password after that. A key-only server with a broken sshd config is reachable only through the provider console, and that console asks for a username and a password. An account with a strong password you have stored is what separates a five minute fix from a reinstall.

FAQ

How do I change the root password on my VPS if I do not know the old one?

Log in as a user that can run sudo and run sudo passwd root. It sets a new password without asking for the old one, because sudo already authenticated you. If no account on the box can run sudo, open the provider console, reboot into the GRUB recovery menu, choose the root shell entry, run mount -o remount,rw /, then run passwd. If root already has a password and that is the one you lost, the recovery shell asks for it, and the remaining route is the provider's rescue image with the disk mounted and chrooted.

Why does passwd say "Authentication token manipulation error"?

Two causes produce that message. The common one is a wrong answer at the Current password: prompt, and the passwd: password unchanged line under it confirms nothing was written. The other is a filesystem that cannot be written, which is what you hit in recovery mode, since / is mounted read-only there. Run mount -o remount,rw / and try again.

Does changing my Linux password also change my sudo password?

Yes. sudo has no password of its own. It authenticates you through PAM against the same /etc/shadow entry that SSH and su use, so there is one password per account. That is also why the first sudo prompt after a change is the real test. Run sudo -k && sudo -v to force that prompt while you still have a working session.

Will changing my password break my SSH keys or my open sessions?

No. Public key authentication never reads /etc/shadow, so keys keep working after a password change, after passwd -l, and after chage -d 0. Sessions that are already open stay open, because SSH checks credentials at login only. The one thing that changes inside a live session is sudo, which asks for the new password once its 15 minute timestamp expires.

How do I force a user to change their password at the next login?

Run sudo chage -d 0 deploy, or sudo passwd -e deploy, which does the same thing. The stored last-change date moves to the epoch, PAM treats the password as expired, and the next interactive login must set a new one before a shell starts. Do not do this to an account used by scripts over SSH: a non-interactive command then fails with Password change required but no TTY available. and never runs.