Reading the report alone: "First, the payload makes sure ~/.ssh exists and appends an attacker-controlled Ed25519 public key to ~/.ssh/authorized_keys, setting permissions to 0700 on the directory and 0600 on the file."

A system where ~/.ssh/authorized_keys has not been modified might be a hint that this did not execute - the article does not mention self cleanup/reverting to previous status behavior by the malware. By default /var/log/auth.log is only of marginal value because outbound SSH connections are not logged by default.