原始链接: https://sshhole.com
Unix 曾将密码哈希存储在可读的 `/etc/passwd` 中；`*` 表示账户没有有效密码。现代系统将哈希移至 `/etc/shadow`，sshd 在此比较 `crypt()` 的输出。如果 `crypt()` 失败，musl 返回 `*` 而非 `NULL`，且 musl 的 SHA-512 crypt 拒绝超过 256 字节的密码，同样返回 `*`。因此，被锁定的 `*` 账户在提供的密码足够长以导致 `crypt()` 失败时，可能产生匹配的 `*`。OpenSSH 2016 年的反枚举代码使用另一个账户的盐对攻击者的密码进行哈希，以处理无效用户，此路径也适用于 `*` 用户。Alpine 后来用 `*` 锁定 root，测试发现基于 musl、不使用 PAM 的 sshd 接受不正当登录。该问题未被注意到的部分原因是 glibc/OpenBSD/PAM 路径不同，且正常账户不受影响，除非目标是被锁定的 `*` 账户。
1980
back in old unix your password hash just sat in /etc/passwd, right next to your username. in a file everyone could read.
in 1980 bill joy put a * there for an account called daemon. nobody's supposed to ever log in as it.
a * isn't a hash, so no password can match it. unix still does this today
3bsd · /etc/passwd · 1980
Addressgithub.com/dspinellis/unix-history-repo/blob/BSD-3/etc/passwd
the next field is the real name. he wrote "the devil himself"
1990s
ok so these days the hash lives in /etc/shadow and looks like $6$abc$k2P9…. the $6$ means sha512, abc is the salt, the rest is the actual hash
you type your password, sshd hashes it with that same salt and checks if it comes out identical. same = you're in. that's it
and if the field is just *? there's nothing to match. type whatever you want, it's never getting you in
1990s
one more rule. if crypt() can't do its job, it returns NULL. like if the salt asks for some algorithm the system doesn't have, there's nothing to compute, so you get NULL instead of a hash
the single unix spec · crypt() · 1997
Addresspubs.opengroup.org/onlinepubs/7908799/xsh/crypt.html
pretty clear.
except a lot of programs never check for NULL. they just compare whatever crypt() gives back with the stored field, hit the NULL, and crash
2012
so musl (the libc under alpine) goes ok fine, crypt() just won't return NULL anymore. if it fails, it returns a single character instead. that character can never match a real password, so programs don't crash, they just see a wrong password
now guess which character they picked for that
""
yep. the star. again.
musl · b3c4cc12 · aug 2012
Addressgit.musl-libc.org/cgit/musl/commit/?id=b3c4cc12
"reportedly."
musl · b3c4cc12 · the diff
Addressgit.musl-libc.org/cgit/musl/commit/?id=b3c4cc12
![diff of crypt_des.c: removed the comment 'Should not happen.' and 'return NULL;', added: return (setting[0]=='*') ? "x" : "*";](receipts/musl-b3c4cc12-diff.png)
"should not happen" gone, NULL gone, "*" in
2012
then musl adds sha512 crypt. the thing is, sha512crypt gets slower the longer the password is, so someone could send one giant password and keep your server busy for a long time. so musl just caps it at 256 bytes and refuses anything longer
musl · 88bf5a8a · aug 29 2012
Addressgit.musl-libc.org/cgit/musl/commit/?id=88bf5a8a
twenty days after the "*" commit btw
musl · crypt_sha512.c @ 88bf5a8a
Addressgit.musl-libc.org/cgit/musl/tree/src/misc/crypt_sha512.c?id=88bf5a8a
so past 256 bytes crypt fails. and when crypt fails… it says "*".
musl · crypt_sha512.c
Addressgit.musl-libc.org/cgit/musl/tree/src/crypt/crypt_sha512.c
literally in the comment the whole time
2016
CVE-2016-6210. ask sshd about a user that doesn't exist and it says no instantly, cause there's nothing to hash. real users take a few ms longer. so just time it and you know who exists
the fix is kinda funny. no real hash to check? sshd grabs some other account's salt and hashes your password anyway, just to waste the same amount of time. still a no, just a slower no
openssh-commits · jul 2016
Addresslists.mindrot.org/pipermail/openssh-commits/2016-July/005428.html
"for invalid users." and also, it turns out, real users with a *.
2019 → 2022
2019. turns out alpine's docker images had no root password. at all. CVE-2019-5021. alpine fixes it by locking root with !
but without pam, ! also kills ssh keys. and cloud images log in with keys.
2022. alpine 3.16 switches root to *. still locked, keys work again
alpine aports · fbe926af · shipped in 3.16, 2022
Addressgitlab.alpinelinux.org/alpine/aports/-/commit/fbe926af.patch
narrator: it did not.
2016 → 2026
why did nobody notice? well, maybe someone did. maybe someone pasted the wrong thing into a password prompt, half a slack message or a whole ssh key, and it just let them in. you've never pasted the wrong thing into a password prompt?? amazing. a fresh box with no passwords set isn't affected. a * in shadow needs a wrong try first. openssh tests on openbsd and glibc, musl doesn't test sshd, and most distros go through pam, which never even calls crypt for a *.
so as far as anyone knows, nobody noticed. as far as anyone knows.
some people got really close though
libc-alpha · debian #714219 · 2013
Addresssourceware.org/legacy-ml/libc-alpha/2013-07/msg00046.html
a debian dev asks glibc to copy musl's "*". six years later debian moves to libxcrypt, which says "*0", and closes the bug. one character away.
musl mailing list · dec 2024
Addressopenwall.com/lists/musl/2024/12/31/2
this thread is about busybox passwd breaking on a 257 character password. same "*", same limit. nobody says "sshd"
openssh-commits · 30 oct 2026
Addresslists.mindrot.org/pipermail/openssh-commits/2026-October/013271.html
a security review fixes pick_salt(). the bug is four lines below it. four days before i found it.
nov 2026
i was messing around with openssh, mostly the boring parts where it talks to libc, like the password code. people don't really look at that stuff, they look at the crypto. so i built sshd every way i could think of (glibc, musl, pam, no pam, shadow, no shadow) and threw like 17,600 weird logins at it. weird hashes, broken accounts, passwords way too long
oh did i say "i"? sorry. i had agent swarms. a lot of them. let's not get into it
every build agreed on every login. except musl without pam. that one said yes to things it shouldn't