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: open the web console in the weasel panel (Console tab), or boot Rescue mode. 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 su/sudo -i, once you already have a working session. 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.

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:

passwdNew 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.

Here the panel does the job: on the server page in my.weasel.cloud there is a Console tab - a web console that works around SSH and the network. Open it, log in as the user you need (the password can be shown with the Reveal password button) and change the password or key as described above. If you can't log in at all, boot Rescue mode: the server restarts from a separate image and your disk becomes available for repair - mount it and fix the files while normal services are offline. If that doesn't help either, open a support ticket (Support → Open Ticket, Tech support department): describe what happened, give the server's IP, and say what you've already tried.

If the data on the server matters, say so in the ticket right away and ask for recovery options, not just a password reset. An OS reinstall wipes everything on the server - only worth agreeing to when it's 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, 2026Password expires					: neverPassword inactive					: neverAccount expires						: neverMinimum number of days between password change		: 0Maximum number of days between password change		: 99999Number 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.

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.

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.

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. 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.

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 there's no access at all under any account, open Console in the weasel panel, and if you can't log in there either, boot Rescue mode (the disk becomes available for repair). A support ticket (Support → Open Ticket, Tech support department) is the last step.

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 Console tab in the weasel panel, then Rescue mode; a ticket is the last resort.
• 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.

🎁 40% off the first month of a new VPS. Promo code GUIDE40
Need a server where you can try commands without fear? The first month is 40% cheaper.
Enter GUIDE40 at checkout. One use per customer.
Pick a VPS and claim the discount →