this post was submitted on 06 Nov 2026
312 points (98.1% liked)
Technology
89506 readers
3376 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This isn't the case, though I can see how the article could lead you to believe that.
It's directly based on password rather than key input. The entire vulnerability is that typing a password longer than 256 characters automatically defaults to
crypt()outputting the*character instead of a normal password hash, which is coincidentally the same default character used as the "hash" (not actually a value you could get from a normal hash, intended to be impossible to get from any normal password for that reason) for the built-indaemonaccount.When the Ars Technica article says "Second, the target system account must be configured to be passwordless", what they mean is the default
daemonaccount, which has a hash set to*by default, and thus wouldn't normally be accessible via any hashed password... unless you happen to find out that the system chooses to not make a hash, and just send*if you type more than 256 characters.Look at https://sshhole.com/ if you want the details.
Technically they're correct though, in a way. If every account has a password, the system isn't vulnerable.
You're also not vulnerable if you use two factor auth, because all 2FA modules require PAM, whereas this vulnerability only exists when PAM is disabled or not installed.
Oh, thanks for details! Missed that.