Earlier quoted context omitted.
What do you mean? The email was sent from a a security research group.
To hazard a guess: it should be standard practice to use public key authentication for ssh (>= 2048 bits rsa or ecdsa), so this attack shouldn't make compromising a system any easier. Better yet, use a Yubikey or equivalent. Other commenters have mentioned this attack getting information on hosted services on the system. But, usually you can get that from a straightforward nmap or other recon tool anyway.
In SSH first every connection is encrypted (before either side knows who the other is, encryption is used already, this is the same approach taken in TLS 1.3), then the server has to authenticate to the client, and then the client authenticates to the server on behalf of a specific user.
User public key authentication is a multi-phase protocol. This would be too awkward for something like HTTP where round trip times may be appalling, but SSH is rarely used at long distances.
In phase 1 the client proposes that it can authenticate for some public key Pn, it sends this proposal to the server, and the server can either say OK, go ahead, or reject this authentication without seeing it done, on the basis that it doesn't trust Pn anyway. It can keep trying different Pn until either it runs out or the server grows tired of this nonsense and disconnects it.
Once it has an OK, in phase 2 the client signs a nonce with the private key corresponding to Pn, which the server can now verify. If the signature checks out, the authentication was successful.
This means an adversary who knows your SSH username but has nothing else would need to literally _guess_ your hypothetical 1024-bit RSA key, not just (already hard but plausibly within the grasp of a resourceful adversary) break a 1024-bit RSA public key to find the associated private key, as your client only tells authenticated servers even the _public_ key.
Aside: One thing I'm surprised I haven't seen done with this part of the SSH design is user TOFU [Trust On First Use]. Lots of home or small / non-security business SSH setups do TOFU for server authentication, sometimes with a fig leaf ("Ask Jerry in IT to tell you the SSH keys" or "The SSH server keys are pasted into this Wiki page"). But I've never seen people do TOFU for the user authentication. In a similarly lax environment why not set up new users, and then when they first connnect just accept whichever public key they offer as "their" key, set that as trusted, and from then on insist on the same key for that user ? I feel like password auth is often left enabled because people are using it for an "initial" authentication step when first setting up without yet trusting any keys - and then never remove it. With "User TOFU" they'd have no incentive to enable password authentication at all.