Typing a password into a live terminal leaves a trace somewhere, which is exactly what chpasswd is built to avoid. You will finish with a controlled way to update passwords for existing Linux accounts in batch mode, while keeping the clear-text input out of shell history and temporary files. This guide describes chpasswd from the Ubuntu passwd package version 1:4.13+dfsg1-4ubuntu3.2. Its installed manual identifies the underlying shadow-utils release as 4.13. Allow about ten minutes for one account, or longer if you are preparing a reviewed batch file.
You need an existing local account name, a root shell or a working sudo policy, and a recovery route such as a second administrator account or console access. This command changes authentication data. Do not test it against a production account unless you have agreed the change and a way to regain access.
Read the installed help before preparing automation. This confirms which binary is being used and avoids assuming that another distribution's options are present:
$ command -v chpasswd
/usr/sbin/chpasswd
$ chpasswd --help
Usage: chpasswd [options]
On this machine, the package reports version 1:4.13+dfsg1-4ubuntu3.2. The manual documents -e for already-encrypted input, -c for a named crypt method, -m for legacy MD5, -R for an absolute chroot directory, and -s for SHA rounds. The local help also lists YESCRYPT among the crypt methods. Treat the installed --help and manual as the authority for this host; do not copy an option from a different release without checking it here.
Checkpoint: run chpasswd --help without sudo. It is a read-only check and should exit successfully.
chpasswd updates existing users. It does not create the account named in its input. Resolve the account before you construct the password command:
$ getent passwd ACCOUNT_NAME
ACCOUNT_NAME:x:1001:1001:Example account:/home/ACCOUNT_NAME:/bin/bash
Replace ACCOUNT_NAME with the real login name, then check the returned record carefully. Do not use an unquoted shell variable for a name supplied by another person, and do not infer the account from a display name. If getent prints nothing, stop. The name may be wrong, the account source may be unavailable, or the user may not be local.
The input format is one user_name:password pair per line. A practical interactive pattern reads the password silently, then sends the pair to chpasswd through standard input:
read -r -s -p 'New password for ACCOUNT_NAME: ' NEW_PASSWORD
printf '\n'
printf '%s\n' "ACCOUNT_NAME:${NEW_PASSWORD}" | sudo chpasswd
unset NEW_PASSWORD
The command after the pipe requires elevated privileges because it updates the system account database. The read value is still present in the shell process until it is unset, and a password can be exposed by careless debugging or process inspection. Use this pattern only on a trusted administrator session, never paste a real password into a shared terminal, and do not add set -x around it.
A successful run normally produces no output and returns status 0. Capture the status immediately if you are scripting:
status=$?
printf 'chpasswd exit status: %s\n' "$status"
Do not interpret silence alone as proof of success. A non-zero status is a failure signal, and the account may need a separate check through the normal login or authentication test for that service.
For several accounts, prepare input with one pair per line and review it before invoking the command. The example below deliberately uses a temporary file name and placeholder values. Do not put real passwords in a file that other users can read:
umask 077
batch_file=$(mktemp)
trap 'rm -f "$batch_file"' EXIT
printf '%s\n' \
'ACCOUNT_ONE:REPLACE_WITH_PASSWORD_ONE' \
'ACCOUNT_TWO:REPLACE_WITH_PASSWORD_TWO' > "$batch_file"
sed -n '1,5p' "$batch_file"
sudo chpasswd < "$batch_file"
status=$?
printf 'chpasswd exit status: %s\n' "$status"
exit "$status"
Replace every placeholder, review the account names and password assignment, and keep the file inside a directory you control. The umask 077 prevents newly created files from being readable by other users. The trap removes the file when the shell exits, including after a normal completion; it does not make clear-text handling risk-free. Do not put the batch in source control, an issue tracker, shell history or an unencrypted shared directory.
When PAM performs password encryption, the manual says chpasswd continues with later users if one update fails and returns an error status. Check the result and inspect the affected accounts individually. Do not assume that a non-zero exit status means that no password changed.
With ordinary input, passwords are supplied in clear text to standard input and are encrypted by the configured PAM path. That is different from -e, which says the supplied values are already encrypted. Never add -e to ordinary passwords: it would treat the text as password data in encrypted form, not hash it for you.
Likewise, avoid selecting -m or an old crypt method merely because it is convenient. The manual describes MD5 and DES compatibility options, but they are weak choices for new passwords. If a deployment has a documented compatibility requirement, verify the method supported by this host, its PAM configuration and the receiving system before changing a batch. The -s rounds option applies only to SHA256 or SHA512 crypt methods according to the manual, with a permitted range of 1,000 to 999,999,999 and 0 meaning the system default. User-password handling through PAM is also subject to the PAM configuration, so a command-line assumption may not control the final policy.
Configuration can affect the result. The relevant files are /etc/pam.d/chpasswd, /etc/login.defs, /etc/passwd and /etc/shadow. Read them with the appropriate care before a large migration. Do not edit /etc/shadow by hand as a recovery shortcut.
If the command fails, keep the exact exit status and error output, then check account names, permissions, PAM policy and the availability of the account database. Rerun only the failed, reviewed entries once the cause is understood. For a batch, assume that earlier entries may already have changed when PAM is in use.
There is no general undo command for a password change. If you entered the wrong password, set a new known-good password through the same controlled procedure, then test access using a separate session. If you locked yourself out, use the approved second administrator, console or recovery process. Never publish the old or new password while asking for help. Remove any temporary input file and unset shell variables after the repair.
getent passwd before the change.