> You have to assume an attacker will remove any traces of themselves from those logs or will stop them from being written in the first place.
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.
Ship them off to where? A system that also can be accessed with your ssh key?
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.
> Ship them off to where? A system that also can be accessed with your ssh key?
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.
I've not seen an enterprise environment where "ordinary" sysadmins also have access to the log hosts. Must be extremely rare setup in a healthy environment.
Likewise selldom to see "logging staff" to actually login to a shell. Logs naturally aggregates to some kind of a service with visualizations, alerting and filtering capabilities.
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.
Holy shit you should not have access to your logging systems/DNS servers with the same exact credentials as your main app servers. Do you let devs onto the HR system with the same ssh key as well?
Elasticsearch existed for years without any authentication on its community tier version, with xpack behind a call with a sales rep and a heavy pocketbook. These days, authentication is provided after you enable the free xpack plugin, but it is not enabled by default and their install guide doesn't exactly point it out to you right away. It starts delving into JVM tuning options before it even references there's this xpack thing you may want to look into.
Console. Cloud login. Different VPN connection. Different credential set then other hosts. Using a hosted service from a completely separate provider. Setting up infrastructure from images without external access.
And I'm sure I missed some - there's a thousand ways to do it.
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.