We've all been there. You type sudo apt update, get prompted for your password, start typing, and... nothing. No asterisks, no dots, no feedback at all. Your cursor just sits there like the terminal is frozen.
If you've ever watched a junior dev encounter this for the first time, you know the exact sequence: they type their password, pause, delete everything, type it again, pause longer, then ask "is this thing broken?" I've onboarded enough people to know this is basically a rite of passage in Linux.
Ubuntu 26.04 is finally changing this behavior. After 46 years of silent password prompts, sudo will now show asterisks as you type. Let's dig into why it was silent in the first place, how the fix works, and how you can configure this yourself on any distro right now.
Why Passwords Were Silent in the First Place
The original reasoning was a security measure. If someone is shoulder-surfing — looking at your screen while you type — showing asterisks reveals the length of your password. A completely blank prompt gives an attacker zero information. They don't even know if you've started typing yet.
This dates back to the original Unix passwd command behavior from the late 1970s. When sudo was created in 1980, it inherited the same philosophy. And honestly? For a time when terminals were shared physical devices in university labs and offices, this made sense.
But the threat model has shifted. Most of us are typing passwords on personal laptops, often alone, or in environments where someone reading your password length off your screen is the least of your concerns compared to, say, phishing or credential stuffing. The UX cost of zero feedback — confusion, mistyped passwords, wasted time — now outweighs the marginal security benefit for most users.
The Actual Fix: pwfeedback
The change is controlled by a single sudoers option called pwfeedback. When enabled, sudo displays an asterisk for each character you type during password entry.
Here's how Ubuntu 26.04 enables it. The relevant sudoers config looks like this:
# /etc/sudoers.d/pwfeedback
Defaults pwfeedbackThat's it. One line. This option has actually existed in sudo for years — Ubuntu is just finally turning it on by default.
How to Enable This on Any Distro Right Now
You don't need to wait for Ubuntu 26.04. You can enable pwfeedback on any Linux distribution (or macOS) that uses sudo 1.7 or later, which is basically everything at this point.
visudo. Never edit /etc/sudoers directly with a regular text editor — visudo validates your syntax before saving, which prevents you from locking yourself out of sudo entirely.
sudo visudoDefaults section:
Defaults pwfeedback# Reset your cached sudo credentials so you get prompted again
sudo -k
# Now run any sudo command and you'll see asterisks
sudo whoamiYou should now see as you type your password instead of a blank void.
Using a Drop-in File Instead
If you prefer not to modify the main sudoers file (good instinct — less risk of breaking things during OS upgrades), you can use a drop-in config:
# Create a separate config file in sudoers.d
echo 'Defaults pwfeedback' | sudo tee /etc/sudoers.d/pwfeedback
# Set correct permissions — sudoers files MUST be 0440
sudo chmod 0440 /etc/sudoers.d/pwfeedbackThis is actually the approach Ubuntu 26.04 takes. Drop-in files in /etc/sudoers.d/ are included automatically and survive package upgrades cleanly.
How to Disable It (If You Prefer the Old Way)
Some of you reading this are already annoyed. "I like the silent prompt. Don't touch my terminal." Fair enough. Security-conscious sysadmins managing servers with shared access might have legitimate reasons to keep the old behavior.
On Ubuntu 26.04, you can revert it:
# Option 1: Remove the drop-in file
sudo rm /etc/sudoers.d/pwfeedback
# Option 2: Override it explicitly
echo 'Defaults !pwfeedback' | sudo tee /etc/sudoers.d/pwfeedback
sudo chmod 0440 /etc/sudoers.d/pwfeedbackNote the ! prefix — that's how you negate a sudoers default.
A Quick Note on the CVE
I should mention: there was a vulnerability related to pwfeedback back in early 2020 (CVE-2019-18634). It was a buffer overflow that could be exploited when pwfeedback was enabled. This was fixed in sudo 1.8.31. If you're running any reasonably current distro, you're patched. But if you're on an ancient system, check your sudo version first:
sudo --version | head -1
# Should be 1.8.31 or later (ideally 1.9.x+)Why This Actually Matters Beyond UX
This isn't just a cosmetic change. Silent password prompts cause real problems:
- Failed automation debugging. When a script prompts for
sudounexpectedly and you can't tell if it's waiting for input or just hanging, you waste time. - Accessibility. Screen readers and assistive tools handle visible feedback differently than empty prompts. Any feedback is better than none.
- Onboarding friction. Every minute a new team member spends confused by the terminal is a minute they're not productive.
The broader shift here is that Linux defaults are slowly catching up to modern usability expectations. We saw this with Ubuntu switching to Wayland by default, adopting systemd-boot in certain configurations, and now this. The "we've always done it this way" defaults are being re-evaluated, and that's a good thing.
Prevention: Setting Up Sane Defaults From the Start
If you're provisioning servers or setting up dev environments with config management, add pwfeedback to your base sudoers template. Here's a minimal Ansible task as an example:
- name: Enable sudo password feedback
copy:
content: 'Defaults pwfeedback\n'
dest: /etc/sudoers.d/pwfeedback
mode: '0440'
validate: 'visudo -cf %s' # validates syntax before writingThat validate line is key — it runs visudo -cf against the file before deploying it, so a typo won't brick sudo access on your remote machines.
Wrapping Up
A 46-year-old default is changing, and it's one of those rare cases where basically everyone agrees it's overdue. Whether you're on Ubuntu 26.04 or any other distro, enabling pwfeedback takes about 30 seconds and saves you from the "is my terminal frozen?" dance forever.
Just remember: use visudo or drop-in files, never raw-edit /etc/sudoers, and verify your sudo version is patched if you're running older systems. Your future self (and your junior devs) will thank you.