You just created a new account and the default credentials are a security liability
You open the terminal, type sudo passwd, and the prompt asks for a new password. You type it twice. It works. But what if it refuses? What if the system complains about password quality, or you need to reset a locked account, or you want to understand why Fedora insists on complex passwords? This guide covers the exact commands, the underlying mechanics, and the edge cases that trip up new administrators.
What is actually happening
When you run passwd, you are not just editing a text file. You are talking to PAM, the Pluggable Authentication Modules system. PAM acts as a gatekeeper between your terminal command and the actual credential storage. It checks password complexity, enforces expiration policies, and writes the hashed password to /etc/shadow. The file /etc/shadow is readable only by root. Regular users can only change their own password, and even then, PAM validates it against the system policy before allowing the write.
Think of PAM as a building security desk. You hand over your new credentials, the desk checks them against the rulebook, and only then does the guard update the master log. Fedora uses yescrypt as the default hashing algorithm on modern releases. The hash is stored in the second column of /etc/shadow, preceded by $y$. The system never stores plaintext passwords. If you lose the original string, you cannot recover it. You can only replace it.
Run journalctl -xeu passwd after a failed attempt. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. You will see exactly which PAM module rejected the input and why.
The fix or how-to
Start with the standard command. If you are changing your own password, run passwd without arguments. If you are an administrator resetting another user's password, prefix it with sudo.
sudo passwd <username>
# WHY: sudo elevates privileges so PAM can write to /etc/shadow
# WHY: passwd without arguments changes the current user's password
# WHY: specifying a username targets a different account for credential updates
The terminal will prompt for the new password twice. Fedora's default PAM configuration enforces a minimum complexity policy. If your password fails, you will see a message like BAD PASSWORD: The password fails the dictionary check. Do not force it. Fedora's pam_pwquality module blocks weak passwords to prevent brute-force attacks. Choose a longer passphrase instead of a short complex string.
For batch operations or scripting, chpasswd is the correct tool. It reads username and password pairs from standard input or a file.
echo "<username>:<newpassword>" | sudo chpasswd
# WHY: chpasswd reads from stdin and updates /etc/shadow directly
# WHY: piping a single line avoids interactive prompts in scripts
# WHY: sudo is required because chpasswd modifies protected credential files
Never edit /usr/lib/security/pwquality.conf. That file ships with the pam_pwquality package. Copy any overrides to /etc/security/pwquality.conf if you must adjust the policy. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Verify it worked
Always confirm the change took effect before closing the terminal. Check the password status and expiration date with the -S flag.
passwd -S <username>
# WHY: -S prints the password status, last change date, and min/max age
# WHY: a status of P means the account has a usable password
# WHY: L or NP indicates a locked account or no password set
Test the new credentials in a fresh terminal session. Use su - <username> to simulate a login without logging out of your current session.
su - <username>
# WHY: su switches to the target user and loads their environment
# WHY: the dash flag ensures a clean login shell with proper PATH and HOME
# WHY: testing here confirms PAM accepted the new hash before you disconnect
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and what the error looks like
The most frequent error is the BAD PASSWORD rejection. This comes from /etc/security/pwquality.conf. The file defines minimum length, character classes, and dictionary checks. If you see BAD PASSWORD: is too simple, the password lacks sufficient character variety. If you see BAD PASSWORD: is too short, it falls below the minlen threshold. Adjust the policy in /etc/security/pwquality.conf only if you understand the security trade-off. Lowering the bar makes the system easier to compromise.
Another common issue is a locked account. If you see Authentication failure or su: Permission denied, the account might be locked. Check the status output again. An L in the first column means the password is locked. Unlock it with passwd -u <username>. If the account was created with useradd -s /usr/sbin/nologin, the shell restriction is separate from the password. Change the shell with usermod -s /bin/bash <username>.
Password expiration also causes confusion. If a user logs in and immediately sees Password expired. change it now., the account hit its maximum age limit. Reset the expiration clock with chage -M 99999 <username> to disable the limit, or set a reasonable rotation period like chage -M 90 <username>. The chage command manipulates the aging fields in /etc/shadow without touching the password hash itself.
SELinux denials occasionally surface during password changes on hardened systems. They show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A missing file context or a misconfigured PAM module usually triggers the denial. Restore the default context with restorecon -Rv /etc/pam.d/ if you suspect a labeling drift.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use passwd when you are changing a single password interactively. Use chpasswd when you are provisioning multiple accounts from a script or a configuration management tool. Use usermod -p only when you are injecting a pre-hashed password string, which is rare and error-prone. Use LDAP or FreeIPA when you are managing more than ten machines and need centralized identity control. Stay on local /etc/shadow authentication if your system is a standalone workstation or a small homelab server.