You’re assuming the attacker has write access to the log storage of the system they ssh into. This is not the norm for production systems. If your auth processes aren’t shipping off logs immediately, your system is broken regardless of ssh.
If not, can an attacker gain access to your email server or DNS with your ssh key? If either is true, they now have access to everything not protected by 2FA that uses an email address they now control.
There's so many things to get right.
You can design a system such that there's a very high likelyhood even a nation-state attacker won't be able to intrude without leaving traces - if you make no mistakes.
Or you know, you could also just rotate your ssh keys in addition to everything else. "I have logs" is really no excuse to forego something that is this easy.
If the ssh key you lost has access to all the critical infrastructure, then, certainly you have a problem. The solution is to not give away write-access keys to your entire system.
> If either is true, they now have access to everything not protected by 2FA that uses an email address they now control.
The initial question was not whether losing a key would cause a breach, but whether a detection mechanism is reliable.
> Or you know, you could also just rotate your ssh keys in addition to everything else.
The question is how does it help? If you can't detect a breach, it will live for as long as your key rotation policy, if not longer. If you can detect and mitigate a breach, it will be closed quickly regardless of your rotation policy.
In those special cases an "extraordinary" sysadmin gets onboard a log host, it is not through the ordinary access ways, such as SSH from where the other sysadmins play around.
The usual networked logging systems that don't have ssh logins, e.g. syslog into ELK stack.
And I'm sure I missed some - there's a thousand ways to do it.
curl -X "DELETE" http://log-server:9200/logstash-*