All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Is it normal for the host node to constantly read my SSH info and Fail2ban config?
English is not my native language, so I translated this with the help of AI.
With so many Linux vulnerabilities surfacing recently and lots of people getting compromised, I started learning more about server security. I learned that the QEMU Guest Agent allows a KVM host to run arbitrary commands on the guest VM. I went ahead and checked the qemu-guest-agent logs across all my machines, and noticed that one of them—hosted on ColoCrossing—behaves differently from the rest.
Roughly every hour, it reads my SSH public key, SSH configurations, and Fail2ban configurations. I don't store private keys on it, so I'm not sure if the read behavior would be different if I did.
My technical knowledge is limited, but this looks suspicious to me. I'm just not sure whether this is actually normal. Has the host node been compromised? Could one of the third-party packages I installed have gotten me compromised? Or is this just routine security scanning and completely normal behavior?
I'm reaching out to the community for help: do any of you see similar activity in your logs?
As a side note, I tried submitting a support ticket several times without success. Logging in and filling out the form went smoothly, but at the very last moment when hitting submit, Cloudflare blocked the request.
Command used:
journalctl -u qemu-guest-agent -e
Log output:
info: guest-file-open called, filepath: /proc/meminfo, mode: r
info: guest-file-open, handle: xxxx
info: guest-file-close called, handle: xxxx
info: guest-file-open called, filepath: /root/.ssh/authorized_keys, mode: r
info: guest-file-open called, filepath: /etc/ssh/sshd_confi#g.d/99-admin-access.conf, mode: r
info: guest-file-open called, filepath: /etc/fail2ban/jail.d/99-admin-ignore.conf, mode: r
While editing this post, I also got blocked by LET's Cloudflare. I think I figured out why I couldn't submit the ColoCrossing ticket: Cloudflare inspects the request body and blocks the path /etc/ssh/sshd_confi#g.d, which I had pasted as part of the logs. If you remove the "#" and try to preview the post, Cloudflare will block you.
Comments
Did you create 99-admin-access.conf and 99-admin-ignore.conf yourself? If not, that's more worrying than the reads. The names look like something added an admin login and a fail2ban whitelist for it. I'd check what's inside both files first.
looks normal
Wonderful question, i was expecting some comment about its contents.
Shocking how nonchalant people just take the qemu agent and its powers. Wild to me. But then, considering how many people put shit up publicly available on the internet, which should never be exposed (hello synology guys 👋 ), i really shouldnt be surprised.
I checked all three paths—none of these files existed because they were never created in the first place.
So, I deliberately created
/root/.ssh/authorized_keysas a test, and I noticed a change in its probing behavior:Yep, write failed. It looks like once the path exists, it starts attempting to write unknown data to it. It probably failed due to insufficient permissions. This time, I went ahead and created
99-admin-access.confand99-admin-ignore.confwith write permissions enabled to see if anything changes next time around.I haven't figured out where the issue lies yet—could be something on my end, or something else entirely. I'll keep investigating.
If anyone could run
journalctl -u qemu-guest-agent -eon their own server to see if they get the same behavior, that would be greatly appreciated.i have same behaviour on 2 different providers. I thinks its how that their control vrtulazor panel uses to check some metric of the guest os.
Those CF waf rules are so incredible naive and blunt.
@OP you may be interested in this thread: https://lowendtalk.com/discussion/220023/neutralizing-the-security-risk-of-qemu-guest-agent-without-removing-it
QEMU Guest Agent is one way that providers can offer you "lazy admin" functionality like resetting your root password from within the panel. Does this absolve your provider from anything nefarious? No, it doesn't. But the above link may be interesting to you.
i don't see a grace full shutdown as lazy admin feature. Disabling the qemu agent is asking for file corruption when the vendor needs to bounce the system
And where did I say anything about graceful shutdown or disabling the guest agent?
To quote CS Lewis, "What do they teach people in these schools."