Describe the bug
When setting a user password in Raspberry Pi Imager v2.0.7 on Windows 11 using copy-paste, the resulting yescrypt hash stored in /boot/firmware/user-data is computed from the password string plus a trailing \n character. Since PAM always strips the newline terminator when reading passwords, the hash never matches — making sudo permanently unusable without a reflash.
Steps to reproduce
- Open Raspberry Pi Imager v2.0.7 on Windows 11
- Select device, OS (Raspberry Pi OS Lite 32-bit Bookworm), storage
- Go to Personalisation → User and paste a password using copy-paste (e.g. from a password generator)
- Complete the flash
- Boot the Pi, connect via SSH
- Try
sudo with the same password → Sorry, try again.
Expected behavior
sudo works with the password entered in Imager.
Actual behavior
sudo always fails. The hash in /boot/firmware/user-data does not correspond to the typed password.
Root cause (verified)
The hash stored in the Windows registry (HKCU\Software\Raspberry Pi\Raspberry Pi Imager\imagecustomization\sshUserPassword) and in /boot/firmware/user-data is the yescrypt hash of <password>\n (password + newline), not <password>.
Verified on the Pi using Perl's crypt() (which calls the system libxcrypt):
perl -e '
my $salt = "$y$jB5$<salt_from_user_data>";
my $target = "<full_hash_from_user_data>";
for my $p ("<password>", "<password>\n") {
my $h = crypt($p, $salt);
print ($h eq $target ? "MATCH" : "no") . ": [$p]\n";
}
'
Output:
no: [<password>]
MATCH: [<password>\n]
Since PAM reads passwords using getpass() (or equivalent), which always strips the newline terminator, the stored hash can never be matched at runtime — regardless of how the password is entered.
Workaround
Reflash the SD card. Before doing so, clear Imager's cached settings to prevent it from reusing the corrupted password hash:
⚠️ Warning — destructive operation: the commands below permanently delete all settings previously saved by Raspberry Pi Imager on this machine (hostname, username, SSH keys, Wi-Fi credentials, etc.). You will need to re-enter them from scratch in the Imager UI. Only proceed if you are aware of what was configured.
# PowerShell (Windows) — run only after reading the warning above
reg delete "HKCU\Software\Raspberry Pi" /f
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Raspberry Pi" -ErrorAction SilentlyContinue
Then type the password manually with the keyboard in the Imager UI — do not use copy-paste.
Environment
|
|
| Imager version |
2.0.7 |
| Host OS |
Windows 11 Pro |
| Target OS |
Raspberry Pi OS Lite 32-bit (Bookworm, kernel 6.12.75+rpt-rpi-v7) |
| Device |
Raspberry Pi 2 Model B v1.1 |
Additional context
Related issues: #1285, #878, #754 (all report password failures post-flash but do not identify the trailing \n as root cause).
Describe the bug
When setting a user password in Raspberry Pi Imager v2.0.7 on Windows 11 using copy-paste, the resulting yescrypt hash stored in
/boot/firmware/user-datais computed from the password string plus a trailing\ncharacter. Since PAM always strips the newline terminator when reading passwords, the hash never matches — makingsudopermanently unusable without a reflash.Steps to reproduce
sudowith the same password →Sorry, try again.Expected behavior
sudoworks with the password entered in Imager.Actual behavior
sudoalways fails. The hash in/boot/firmware/user-datadoes not correspond to the typed password.Root cause (verified)
The hash stored in the Windows registry (
HKCU\Software\Raspberry Pi\Raspberry Pi Imager\imagecustomization\sshUserPassword) and in/boot/firmware/user-datais the yescrypt hash of<password>\n(password + newline), not<password>.Verified on the Pi using Perl's
crypt()(which calls the systemlibxcrypt):Output:
Since PAM reads passwords using
getpass()(or equivalent), which always strips the newline terminator, the stored hash can never be matched at runtime — regardless of how the password is entered.Workaround
Reflash the SD card. Before doing so, clear Imager's cached settings to prevent it from reusing the corrupted password hash:
Then type the password manually with the keyboard in the Imager UI — do not use copy-paste.
Environment
Additional context
Related issues: #1285, #878, #754 (all report password failures post-flash but do not identify the trailing
\nas root cause).