Comment on Update all your stuff, NOW - again.
tapdattl@lemmy.world 1 hour ago
I’m assuming this is only if you allow password authentication? If you’re only allowing certificate based auth you should be safe, right?
Comment on Update all your stuff, NOW - again.
tapdattl@lemmy.world 1 hour ago
I’m assuming this is only if you allow password authentication? If you’re only allowing certificate based auth you should be safe, right?
smiletolerantly@awful.systems 1 hour ago
NO! Exactly the opposite, that is the problem. Key-only is a prerequisite for this.
cecilkorik@piefed.ca 38 minutes ago
I think there is some confusion and potential for misinformation here. SSH in key-only mode (common configuration) protects you from this problem, because it never accepts or even attempts any passwords at all, regardless of length. SSH in password-allowed mode with at least one user who might be a key-only USER by merit of having a password hash of “*” (not a valid password hash) is a prerequisite for this. That is a very different and very common thing, as most systems come with at least one key-only user by default. But gaining access to that user with an incorrect, invalid password still requires having passwords enabled at all.
To be clear: Password access enabled is a prerequisite, and by extension, password access disabled (key-only) prevents this.
The website you linked clearly defines that all of these conditions must be true for you to be vulnerable, and as far as I can tell, it is exactly correct:
The * account which they suggest potentially being “key only” is the prerequisite you are talking about, but having SSH itself key-only (which is best practice anyway) prevents the attack entirely.
DrakiaXYZ@lemmy.ca 33 minutes ago
The linked article literally says you need password login enabled at the ssh level. The account however needs to not have a password set