in re: “SSHhole” (“log in to any account with no hash using a password that’s 1024 > n > 256 in length): two important notes:

1. to log onto root like demonstrated on the PoC page, you need PermitRootLogin, which is almost never set to yes. The default is PermitRootLogin prohibit-password, which is what Alpine has been shipping with.

2. Only root shipped without ! in the hash field. Every other account ships with !, so as far as I can tell, they were never vulnerable.

Verdict: NOTHINGBURGER AGAIN! There are valid reasons to enable ssh password auth, but if you’re allowing it for root, you’re just asking for trouble. Don’t Do That.

aside: i may be stupid, but my /etc/shadow.apk-new shows root:::0::::: on a system that hasn’t been updated today. Notice the lack of the star.

Is anything on sshhole dot com even real? Is this yet another case when someone is just spewing bullshit about a possible insecure configuration that has never actually been seen in the wild?

@domi I would not say nothingburger but a bit less severe than it appears at first

@Mae i know i’m extrapolating but at some point it’s the equivalent of setting yourself up for it. at which point do we go from “sure, this is a possible vulnerability that someone could have configured themselves into” to “CVSS 10.0: # echo -e password\npassword | passwd REMOTE RCE VULNERABILITY PATCH NOW”

@domi tbh "PermitRootLogin yes" is not too unusual on embedded systems where one might not have a dedicated reason to create a separate account.

@fogti yeah but those aren’t exposed to the ‘net. and if they are, you should be using keys, not passwords. allowing key login is the default, which has been secure.

@Mae @domi welcome to the age where every CVE is described as catastrophic thanks to infosec clout chasing

@domi and on standard gentoo, the following ships in /etc/shadow:
alt:*:9797:0:::::
operator:*:9797:0:::::
shutdown:*:9797:0:::::
sync:*:9797:0:::::
bin:*:9797:0:::::
daemon:*:9797:0:::::
adm:*:9797:0:::::
lp:*:9797:0:::::
news:*:9797:0:::::
uucp:*:9797:0:::::
portage:*:9797:0:::::
nobody:*:9797:0:::::

and sure, none of those allow a normal login. but they're fully capable of e.g. shutting the system down, so DoS.

@fogti are they now capable of shutting down the system? FWIW logging in is already bad enough for information disclosure reasons, but I don’t think you’re right

also gentoo ships with glibc by default. so it’s a possible configuration, but i doubt it’s especially common

@domi sure, key login should be the default (tho in some places it isn't e.g. due to kerberos usage + interaction with non-kerberized systems), but password login is often still a fallback, especially when bootstrapping login via key.

so I wouldn't deem this "nothingburger" exactly.

@fogti ok

@domi @fogti Also, if you're deliberately allowing root login via password... you have probably set a password.

@domi
the real part is "i had agent swarms"

@ozzelot oh that’s when i stopped reading

@domi What the… that's actually way more concerning, empty password field means no password at all.

I know because well… https://github.com/shadow-maint/shadow/pull/315

@domi Ah wait, no /etc/shadow not /etc/passwd, but well you need to look at both and the one that needs a star is /etc/passwd (hence why I got mislead).

@lanodan

$ cat /etc/passwd.apk-new 
root:x:0:0:root:/root:/bin/sh

no dice…

@fogti
by don't allow normal login you mean, have /bin/{false,nologin,shutdown} as their shell? I'm not sure this will block ssh with specified command, or sftp...
@domi

@wolf480pl @domi afaik ssh still passes through the login shell, so such shells do prevent login (otherwise, they would be useless)

@fogti @wolf480pl but this takes us back to square one, shouldn’t they be set to nologin in the first place, and thus be invulnerable?

@domi not familiar with alpine so i'm not sure either

but the alpine website itself says that root ships with *

https://www.alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/#:~:text=root,doas%2E

(you are correct about PermitRootLogin)

@steffo there seems to be a difference between “base image” and what I have installed, possibly due to installing vs unpacking a minirootfs. idk

@domi @wolf480pl shutdown, halt and sync aren't.

@fogti @wolf480pl look, idk about gentoo but on alpine this genuinely never worked

@domi @fogti @wolf480pl Reminds me that on my OpenSuse chroots it's like this, so pretty sure Alpine could toss out a lot of legacy:

$ cat /mnt/opensuse/etc/passwd
root:x:0:0:root:/root:/bin/bash
messagebus:x:499:486:User for D-Bus:/run/dbus:/usr/bin/false
haelwenn:x:203:100::/home/haelwenn:/bin/bash
lp:x:202:491:Printing daemon:/var/spool/lpd:/usr/sbin/nologin
systemd-timesync:x:484:484:systemd Time Synchronization:/:/usr/sbin/nologin

(haelwenn being my account, and yeah my uid is from ancient ranges)

@lanodan @fogti @wolf480pl i should change my uid to be very low, as a treat :3

@domi @fogti there's like a billion embedded systems on the net, have you not opened shodan?

@fogti @domi at least historically, i've never seen an embedded device with ssh password auth and without PAM that wasn't running dropbear instead

@r @fogti @domi however this is true

@domi @fogti Re embedded systems not exposed, have you missed the whole supermarket freezer thing?

@cm @fogti that wasn’t ssh now, was it? there’s a difference between internet access and ports exposed publicly

(also, yeah, i did miss it. and i’d prefer for it to stay that way)

@whitequark @fogti sigh sure. everything else I wrote holds true

@domi i disagree with it being a nothingburger, but it is certainly niche. it reproduces against alpine. if you set a password on root (or any user other than alpine) then you can SSH into the alpine user with a 257-char password (and it has passwordless doas by default, so you get root)

@mildsunrise @fogti @domi but “the alpine user” is a concept that doesn’t exist anywhere besides one cloud image for AWS, which is still rather niche

@domi almost like boiling down every vuln to a single number is stupid lol

@domi I hate the infosec industry

@Mae speaking with several hours of hindsight: perhaps a better way to put it would be “overblown”, not “nothingburger”, so i’ll give you that.

but saying “the chain is severe, but ultimately rarely harmful” just doesn’t sell…

@ptrc @fogti @domi AFAIU it exists in all of the cloud images. I tested with the generic tiny-r0 VM image https://tech.lgbt/@mildsunrise/117564481242575700

@mildsunrise @ptrc @fogti the likelyhood of you setting password on root and not alpine in a setup like this is. quite low

i’d wager that most people will either need password for doas, or will log onto root directly with a key, so they don’t need a password anywhere. I host a good number of alpine systems and not one was affected…

@domi The vuln is real, I was able to reproduce it.

@nullenvk @domi @Mae I'd be quite a bit more specific: not clout chasing (that's mostly individuals) but marketing by security companies

@joepie91 @domi @Mae sufficiently stupid marketing is indistinguishable from clout chasing

@domi said nothingburger is also pretty much an advertisement for for an agentic pentesting or whatever the fuck company

the ai deepthroating nowadays is so insane, it borders full on psychosis istg

@protos you almost never need to ssh as root. i fail to see the relevance

@domi you also never need to ssh as some other user, and root is what a VPS will give you

@protos i’m a proponent of using user accounts instead of having everyone log in as root, one typo away from disaster on every server

and lol, lmao @ using default VPS hoster configuration as something to base your opinions around…