Is the name of the vulnerability literally *sshole?
this post was submitted on 06 Nov 2026
342 points (97.8% liked)
Technology
89533 readers
2536 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
tldr: disable password auth in ssh.
Also name misses the point I think, it's a musl-hole.
i mean assholes are muscle holes.
load more comments
(1 replies)
What an aSSHole!
The only time I ever exposed my SSH port to the WAN, I got about 750 connection attempts from China and 250 attemps from Russia per hour.
Yet some people will still say with a straight face "tHeRe iS nO hYbRiD wAr!1!1"
Not in Ba Sing Se at least...
This was about 20 years ago btw. I know it's gotten worse. But it started earlier than most think.
Yeah, BBC has a whole documentary about it. Plus the russian state department basically published it all in a propaganda manual. They don't exactly try to hide this stuff...
New friends from all over the world!
yeah, while reading this i was going "What maniac exposes SSH to WAN anyway...?" the whole time. I fail to see any reason or point that can be justified exposing SSH to WAN.
I used to have a synology NAS that would sleep of death itself. Synology support asked me to port forward SSH to the open internet and set no password so they could pull logs over the next few weeks.
Yes, it was legit synology support not a scammer.
No, I haven’t bought synology ever again.
What do you use now? Qnap?
I build my own stuff now. I tried qnap after synology but it just sucked in different ways.
Not the person you responded to, but I'll give my unsolicited advice: I switched to Unifi NAS. QNAP has had a lot of security nightmares, and a bad habit of EOLing devices.
The best option might actually be using an old workstation and going with something like TrueNAS, but I enjoy the convenience of a purpose built box.
One big difference between Unifi NAS and something like QNAP or Synology, is that the Unifi NAS only does NAS work, it doesn't run containers or "apps". You need separate compute if you want to run containers.
One thing I didn't know before buying a UniFi Nas was it does not support raid0 or jbod unfortunately
The sounds like a big one. Doesn't affect me, but you'd think a lot of people would want one of those.
Unifi actually sounds better. I'm the same and want my NAS to be optimized by someone smarter than me. I've been using qnap and don't really care for half the crap they offer. They're not as enshittified as Synology, but they're getting there.
99.999% of that is over IPv4. I leave IPv6 open to WAN for my own use and it's not a problem.
Thanks for the intel
Yeah it's crazy. Are they just constantly pinging every possible ip address on every possible port every second? I opened a port for 1 day and the traffic made me uncomfortable enough to rearchitecture my entire self host setup
practically need to rotate logs every hour if you foolishly leave ssh open on a open network. usually a bastion with ssh listening to port 34000 or such is a good first step.
that said the conditions for this exploit are fascinating. no pam, shadow password set to *, using a alternative to glibc. The sacrifices to be more efficient feel on par with replacing a tank's armor with paper mache and hope.
The best armor is to not get hit!
Further, OpenSSH using musl (pronounced muscle) must not use PAM (pluggable authentication modules),
which Alpine doesn't ship by default. Maybe one or the other remote administration suite depends on it, but those are often suspectible to exploits anyway. But you don't expose either to WAN, right?
Can they please take a break from having vulnerabilities
nah, find and fix as many as possible.
It seems like the pattern emerging is that AI is great at finding these obscure vulnerabilities that are only exploitable on very particular systems with very particular, non-typical configurations, and only on nights where unicorns fart candycorn.
Sure, fix them, but the hype is too much. Also, disable password auth on SSH already. Jesus. Keys arnt that hard.
More like AI is much faster at finding obscure vulnerabilities, because it doesn't get tired of digging into the mind-numbing details of human-generated spaghetti code. Give a human the same kind of task, and they would die of boredom 12 hours into it.
We're entering an age where AI is quickly cleaning up the stupid security holes that have been created by decades of human mistakes, and will continue to be this way until increased AI security reviews will become more standard. The tribals wielding spears will continue to get shot by superior firepower until they adapt to the same weapons and protection themselves.
"Cleaning up" seems a little generous. It's finding them, but someone still has to patch them.
Most vulnerability patches are a few lines of code. Finding it is the hard part.
Even then, the AI session that found it probably already has a solution to fix it.
load more comments
(3 replies)
I agree about the AI, but desktop Linux has never been under haxxor pressure the same way windows or apple has. I also think the newer parts of the userbase are less technical than even ten years ago. Previously undocumented bugs found and squashed is great for everyone.
load more comments
(2 replies)
load more comments
(5 replies)
Given this is a vuln when entering the password, just turn off password auth and use ssh keys only. It's what you should be doing anyway.
The vuln is specifically for key-based accounts:
Second, the target system account must be configured to be passwordless. Passwordless accounts are commonly used for accounts that use certificate-based authentication.
"passwordless" here means that the account doesn't have a password. What the person you're replying to means is that password authentication should be completely disabled in the SSH config, as that's the only way to exploit this issue.
But passwords need to be enabled for SSH. You must submit a faulty password of a specific kind, and the SSH server misinterprets it for passwordless accounts, which means the server must be configured to allow you to attempt a password.
load more comments
(1 replies)
load more comments
(2 replies)
Fuck. OpenWRT might fit that bill.
Edit: it does, kind of:
https://forum.gl-inet.com/t/sshole-exploit-does-not-impact-gl-oem-firmware/72657
The person who discovered *sshole said OpenWRT is affected, but by default, that OS uses the Dropbear package, not OpenSSH, for SSH connections (though maintainers provide instructions for installing the latter).
Most ssh ports should be accessed through a VPN anyway, not exposed directly to the internet
Are you sure the VPN server has the smaller attack surface than the SSH server?
Wireguard and apps based on it (like Tailscale) don't respond at all unless the data is signed with the key of a configured peer (or with Tailscale, a system on your tailnet that passes the ACL). It's literally impossible for an outsider/attacker to detect with a port scan since it just ignores unauthenticated packets.
The Wireguard codebase is also extremely small. The core Wireguard implementation (the version in the Linux kernel) is around 5,000 lines long, so an experienced developer can read through all the code if they dedicate a day or two to it, and understand how it works.
For comparison, OpenVPN is around 70,000 lines of code and OpenSSH is around 150,000 lines of code. There's a huge number of features in SSH!
load more comments
(6 replies)
load more comments
(1 replies)
view more: next ›