Changing passwords on Ubuntu: your own, another user's, and root

One command changes a password on Ubuntu, passwd, but it behaves differently depending on who runs it and whose account it touches. Change your own and it asks for the old one. Change someone else's through sudo and it asks for nothing but the new one. The root account is its own case entirely, especially once direct root login over SSH is turned off, which it usually is. This guide walks through all three ways to change a password on Ubuntu, plus what to do if you're locked out completely, how to check a password's expiry date, and what the most common errors actually mean.

In short. Changing your own password as a regular user: just passwd, it asks for your current one first. Changing another user's password as a sudoer: sudo passwd username, no question about their old password. Setting or changing the root password: sudo passwd root, same deal, no old password asked. To actually work as root: sudo -i (not su - unless you already know root's password). Locked out of every account: you need the server's web console or recovery mode from the panel, bypassing the network entirely. Check expiry with chage -l username, disable it with sudo chage -M 99999 username. If you see passwd: Authentication token manipulation error after any of this, check df -h first - a full disk causes it about as often as anything else.

Your own password as a regular user: passwd

This is the case you hit most: you're logged into the server under your own account and want a new password, because the old one leaked, was too weak, or it's just time. One command handles it:

passwd

Ubuntu never stores passwords in plain text, only as a hash in /etc/shadow, a file only root can read. passwd confirms you actually own the account before letting you set anything new, so it asks for your current password first:

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

• Current password is your own password, not root's - passwd asks for the password of whichever account you're currently running as;
• New password and Retype new password ask for the same string twice to catch typos; nothing shows on screen while you type, not even asterisks, that's normal;
• passwd: password updated successfully is the only reliable sign the change actually took.

If you see something about an authentication token or password length instead of that line, skip to the errors section below - both cases are covered there.

Another user's password: sudo passwd

The other common job: you administer the server, you have sudo, and someone else needs a new password, either a teammate or a user who forgot theirs. The difference from the previous case is that you don't know their current password and you don't need to - the command never asks for it:

sudo passwd alice

New password:
Retype new password:
passwd: password updated successfully

The logic is simple. sudo already confirmed who you are by asking for your own password (or by reusing a still-valid ticket from a recent sudo call). From there the command runs as root, and root can set any user's password without knowing what it used to be - that's the whole mechanism behind restoring someone else's access. The difference between passwd and sudo passwd alice isn't the command, it's whose authority you're acting under.

One catch: without sudo, a regular user can only touch their own password. Running passwd alice without sudo, if you aren't root, fails with passwd: You may not view or modify password information for alice - that's the system working as intended, not a bug.

The root password: sudo passwd root

Root is the unrestricted account, and on a Ubuntu VPS it's usually the one account with direct SSH login turned off. It still has a password entry in /etc/shadow though, and you sometimes need to set or change it: to use su later, to reach a recovery console, or to sign in some way that doesn't go through SSH. With sudo, the process is identical to setting any other user's password:

sudo passwd root

New password:
Retype new password:
passwd: password updated successfully

Same reason as before, no prompt for root's current password: the command runs as root because of sudo, not because of your own account's privileges.

A password you set this way lets you become root locally, through the server console or su/sudo -i. Logging in directly as root over SSH is a separate setting, PermitRootLogin in /etc/ssh/sshd_config, and most Ubuntu images ship with it disabled or restricted to key-based auth. Changing root's password doesn't touch that setting - if you genuinely need direct root SSH access, treat it as its own decision, and in most cases a sudo user is the better choice anyway. Verify the exact default on current WeaselCloud images.

Becoming root to work in that shell: sudo -i vs su -

Sometimes a one-off password change isn't the goal, you need a full root session: installing a package that expects an explicit root environment, or sorting out permissions in system directories. There are two near-identical ways to get there, and they behave differently around passwords.

su - is the classic "switch to another user" command, but it asks for the password of the account you're switching to - root's password. If you don't know it, or it was never set, the command simply refuses:

su -
Password:

sudo -i opens a root session through sudo, so it asks for your own password instead (or nothing, if your sudo ticket is still fresh):

sudo -i

The prompt changes to root@hostname:~#, that's your confirmation you're inside a root session. Run plain passwd there with no arguments and you get a third variant of the behavior: you're changing root's own password, but root is exempt from confirming its current one, even for itself:

passwd

New password:
Retype new password:
passwd: password updated successfully

When to use which: if you have sudo but don't know root's password (common on a fresh VPS, where root ships password-locked from the start), reach for sudo -i, not su -. su - only makes sense once root's password is already known and typing it is quicker than going through sudo.

Locked out of every account

Sometimes it's worse than a forgotten password: you've lost your own user's password, you don't know root's, and your SSH key is gone or this is an inherited server with none of your keys on it at all. None of the commands above help here, they all need at least one working session to start from.

The way back in bypasses the network and SSH entirely. WeaselCloud's panel has a server web console for exactly this: it shows you the machine's screen and keyboard as if you were physically in front of it, and it keeps working even when the network or the SSH daemon is unreachable. From there you can log in locally under an account you still know, or boot into recovery mode, a special boot option that drops you into a root shell with no password required, and reset whichever user's password you need with plain passwd.

Verify: the exact menu wording for the web console and recovery mode in the current WeaselCloud panel, and the click-by-click sequence of screens - confirm against the live interface and capture real screenshots for the final version.

If you genuinely have no known password and no SSH key for the server at all, and the data on it matters, going through the console is faster and safer than guessing. An OS reinstall from the panel is the last resort, worth it only when the server is empty or you have a backup elsewhere.

Password expiry: chage

Ubuntu can attach an expiry to any password: after how many days the system forces a change. That's managed separately from the password itself, through chage (password "age"). Check the current settings:

chage -l username

Last password change : Sep 11, 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

This is the real output for a freshly created user on Ubuntu 24.04, verified live on a test server on September 11, 2026. That 99999 on the maximum-days line is there by default, nobody set it on purpose.

• Password expires is the date the password stops working; never means expiry is effectively off;
• Maximum number of days... is that lifetime in days; 99999 days is roughly 274 years, the standard Linux way of saying "forever", not a special sentinel value;
• you can run chage -l on your own account without sudo; for anyone else's you need sudo chage -l alice.

On a fresh server you'll most likely see exactly what's shown above, never and 99999. If instead you see an actual small number, that's not default behavior anymore, it's someone's security baseline layered on top of the image - some hardened or corporate templates set expiry to something like 90 days - and the password really will stop working at some point. To turn off the forced change:

sudo chage -M 99999 username

What you see: nothing on success - confirm with another chage -l; Maximum number of days... should now read 99999, and Password expires should show a date hundreds of years out, or never.

Common errors when changing a password

"passwd: Authentication token manipulation error". The frustrating part is that this exact string shows up in two unrelated situations, and the message itself gives you no way to tell which one you're in.

The first cause is that the system literally cannot write the new password hash to disk: the filesystem is full or mounted read-only. It's usually not the root filesystem that fills up but /boot, which accumulates old kernel versions after a run of upgrades. Check:

df -h

Look at the Use% column for / and /boot; anywhere near 100% is your answer. Free up space (sudo apt autoremove usually clears old kernels off /boot) and run passwd again.

The second cause is that you typed a new password three times in a row and each one failed the complexity check, and after the third rejection passwd gave up with this same error, having changed nothing. When this happens there's normally a warning above the final line, something like BAD PASSWORD or "You must choose a longer password" - scroll up, don't just read the last line. Verify the exact warning text and retry count on the current libpwquality version in 22.04/24.04.

"You must choose a longer password" / "BAD PASSWORD". This isn't a failure of the command, it's the password quality module rejecting your input, usually for being under the minimum length (often 8 characters) or too repetitive. Just pick something longer and less predictable. On many systems root is exempt from this check by default and can set itself any password at all, short ones included, so don't be surprised if the same weak string sails through as root with no complaint. Verify the enforce_for_root behavior on current images.

Account locked after failed login attempts. If someone, possibly you, typed the wrong password several times in a row while logging in, the system may lock the account temporarily. That's pam_faillock at work (older systems used pam_tally2 for this, current Ubuntu doesn't). The command itself is confirmed present: the /usr/sbin/faillock binary ships by default on Ubuntu 24.04, nothing extra to install. Check the failure count:

sudo faillock --user alice

The output is a table of timestamps for each failed attempt. Verify the exact table format (column names) - reproducing an actually locked record through su didn't work in a reasonable amount of time, because su doesn't run the full PAM stack the way a real SSH login with a wrong password does; this needs a few genuinely failed SSH connections in a row. If there's a count and login still fails, clear it:

sudo faillock --user alice --reset

Worth being clear on: a faillock lockout has nothing to do with the password itself, which stays the same the whole time - the system is just refusing to use it for a while. Changing the password doesn't clear the lockout; only resetting the counter does.

passwd

sudo passwd alice

sudo passwd root

su -

FAQ

How do I change the root password on Ubuntu?

With sudo access, the direct route is sudo passwd root: it asks for the new password twice and nothing about the current one. Alternatively, enter a root session with sudo -i and run plain passwd inside it. Setting root's password doesn't enable direct root login over SSH, that's a separate setting, PermitRootLogin in sshd_config.

I'm locked out of my Ubuntu VPS, what now?

If you still have one working SSH key or another user with sudo, log in under that and run sudo passwd username for the account you need. If there's no access at all under any account, use the server web console in the control panel, it shows the machine's screen bypassing SSH and the network entirely, and from there you can either log in locally or boot into recovery mode and reset the password from there.

Why doesn't sudo passwd ask for the current password?

Because sudo already confirmed your identity by asking for your own password when you started the sudo session. From that point passwd runs as root, and root can change any user's password without knowing what it used to be, that's exactly how restoring access for someone else works.

What does passwd: Authentication token manipulation error mean?

Most often the system can't write the new password to disk: the filesystem is full, especially /boot after old kernels pile up, or it's mounted read-only. Check df -h. The other likely cause is that the new password failed the complexity check three times in a row and passwd gave up with the same message; look for a warning like BAD PASSWORD just above the final line.

How do I check when a Linux password expires?

chage -l username (no sudo needed for your own account, sudo required for someone else's) shows the expiry date on the Password expires line and the maximum lifetime in days. never means there's no forced expiry. Turn it off with sudo chage -M 99999 username.

Tested on

Every passwd, sudo passwd, and sudo -i + passwd output shown in this article, plus the chage -l output, is real - captured on a test server running Ubuntu 24.04 on September 11, 2026, not reconstructed from memory. The faillock binary is present by default on the same test box, but a locked record and the exact output table format weren't reproduced live in time - that's flagged in the checklist above. This particular command sequence wasn't run separately on Ubuntu 22.04, but passwd, chage, and faillock ship in the same base packages (passwd, libpam-modules) there too, and this part hasn't changed between releases. Exact pwquality warning wording, enforce_for_root behavior, and the PermitRootLogin default are all in the checklist above, not confirmed live.

Takeaways

• Your own password: just passwd, it asks for your current one.
• Someone else's password, with sudo: sudo passwd username, no question about the current one.
• Root's password: the same, sudo passwd root, no old-password prompt.
• Don't know root's password but have sudo: use sudo -i, not su - (which asks for root's own password).
• No access under any account: the server web console or recovery mode in the WeaselCloud panel, bypassing the network.
• Check expiry with chage -l username, disable it with sudo chage -M 99999 username.
• Authentication token manipulation error: check df -h first, then password complexity.
• A lockout after failed logins clears with sudo faillock --user username --reset, not by changing the password.

Next steps

• Common Linux server problems - the other typical VPS failures and how to catch them.
• How to restart networking on Ubuntu and Debian - if the network turns out to be down separately from the password issue.
• nginx errors: 404, 502, 504, 413 - when access to the server is fine but the site still won't respond.