Using password login renders this vulnerability useless.

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-in daemon account.

When the Ars Technica article says "Second, the target system account must be configured to be passwordless", what they mean is the default daemon account, 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.

Other way around. This requires a passwordless account configured with sha256 or sha512 password hash, musl system with openssh installed, no PAM, and password authentication allowed:

When logging into a passwordless account, the attacker can gain access by inputting more than 256 characters in the password field.