There is some evidence it's scrubbing logs so we might not even have that.
But in the case of this specific attack, probably the safest approach would be to watch and track what processes are being spawned by sshd. Which in retrospect is probably advisable for any network daemon. (Of course, lots of them will be sloppy and messy with how they interact with the system and it might be next to impossible to tell attacks from “legit” behavior. But sshd is probably easier to pin down to what’s “safe” or not.
So if I only use pubkey auth and ED25519, there's no risk?
Besides this, just to understand it better, if someone tries to login to your server with the attacker's certificate, the backdoor will disable any checks for it and allow the remote user to login as root (or any other arbitrary user) even if root login is disabled in sshd config?
But, one clever thing about this attack is that the commands being run wouldn’t be caught by typical user-login tracking, since there’s no “login”. The attacker is just tricking sshd into running a command.
Specifically how did the xz library patch/hook/inject into the openssl functions that verify RSA signatures?
1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack
2. The XZ library injects its own versions of functions in openssl that verify RSA signatures
3. When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called
4. The certificate, in turn, can contain arbitrary data that in a normal login process would include assertions about username or role that would be used to determine if the certificate is valid for use logging in as the particular user. But if the hacked functions detect that the certificate was signed by a specific attacker key, they take some subfield of the certificate and execute it as a command on the system in the sshd context (ie, as the root user).
Unfortunately, we don’t know the attacker’s signing key, just the public key the hacked code uses to validate it. But basically this would give the attacker a way to run any command as root on any compromised system without leaving much of a trace, beyond the (presumably failed) login attempt, which any system on the internet will be getting a lot of anyway.