2. NodeSeek
  3. 【被黑了吗？】CSS通过宿主机，读取我的SSH、Fail2ban

【被黑了吗？】CSS通过宿主机，读取我的SSH、Fail2ban

0-show 2026-10-29 13:16 1

查询命令：journalctl -u qemu-guest-agent -e



Oct 29 12:00:47 localhost qemu-ga[651]: info: guest-file-open called, filepath: /proc/meminfo, mode: r

Oct 29 12:00:47 localhost qemu-ga[651]: info: guest-file-open, handle: 2690

Oct 29 12:00:47 localhost qemu-ga[651]: info: guest-file-close called, handle: 2690

Oct 29 12:05:03 localhost qemu-ga[651]: info: guest-file-open called, filepath: /root/.ssh/authorized_keys, mode: r

Oct 29 12:05:13 localhost qemu-ga[651]: info: guest-file-open called, filepath: /etc/ssh/sshd_config.d/99-admin-access.conf, mode: r

Oct 29 12:05:14 localhost qemu-ga[651]: info: guest-file-open called, filepath: /etc/fail2ban/jail.d/99-admin-ignore.conf, mode: r



因为最近漏洞高发，专门了解了这块知识

原来宿主机可以通qemu-guest-agent下发任意命令给小鸡，不知道怎么装上的，系统都DD过



我查了手上所有机器的qemu-guest-agent日志，就CCS和DediRock特别，它读取SSH公钥、SSH配置、Fail2ban配置

也不知道宿主机读取这些，究竟要干嘛，如果存放私钥会不会被读取？

有无高手去看一下，并解答

最新回复 (11)
  • 0-show 楼主 10-29 13:16
    1楼

    工单还没发，论里高手多，相信很快就会知道为啥



    有没有自查过的，都是什么结果

    查询命令：journalctl -u qemu-guest-agent -e

  • freenessfish 10-29 13:18
    2楼

    蹲个结果

  • keyhappy 10-29 13:19
    3楼

    蹲结果

  • 这瓜保熟吗 10-29 13:20
    4楼

  • linbei 10-29 13:21
    5楼

    蹲蹲

  • lovexiaoyi 10-29 14:01
    6楼

    默认卸载agent

  • 0-show 楼主 10-29 16:03
    7楼

    没有人有同样情况？

  • ElonMuskX 10-29 16:05
    8楼

    蹲个结果

  • 0-show 楼主 10-29 16:11
    9楼

    论里没有高手？

  • nordgeek 10-29 16:13
    10楼

    AI 回答：


    从这段 journalctl -u qemu-guest-agent -e 日志来看，目前看到的是 QEMU Guest Agent 被调用读取文件的记录，不能仅凭这些日志判断服务器已经被入侵。 但其中涉及 SSH 登录密钥和 SSH、Fail2ban 配置，值得进一步核实。



    1. 逐条分析日志

      时间 操作 判断

      12:00:47 读取 /proc/meminfo 通常用于获取虚拟机内存信息，属于常见管理操作

      12:05:03 读取 /root/.ssh/authorized_keys 需要核实是谁在读取，以及 SSH 公钥是否被修改

      12:05:13 读取 99-admin-access.conf 可能是管理平台检查 SSH 配置

      12:05:14 读取 99-admin-ignore.conf 可能是管理平台检查 Fail2ban 忽略规则


    需要注意：这些日志记录的是 Guest Agent 收到的文件读取请求，并不直接证明请求者的身份，也不代表文件内容已被修改。


    如果你的 VPS 提供商通过 QEMU Guest Agent 管理虚拟机，平台可能会读取这些文件。不过，具体是否属于正常行为，需要结合提供商的管理机制和对应时间的系统日志判断。

    2. 先执行以下只读检查

    请在 Debian 13 VPS 中逐条执行，不要先删除文件或重装系统。

    第一步：检查 SSH 公钥和相关配置

    sudo stat /root/.ssh/authorized_keys

    /etc/ssh/sshd_config.d/99-admin-access.conf

    /etc/fail2ban/jail.d/99-admin-ignore.conf


    sudo ssh-keygen -lf /root/.ssh/authorized_keys


    sudo cat /etc/ssh/sshd_config.d/99-admin-access.conf


    sudo cat /etc/fail2ban/jail.d/99-admin-ignore.conf


    重点关注：



    • authorized_keys 中是否存在你不认识的公钥。

    • SSH 配置是否允许了不符合预期的登录方式。

    • Fail2ban 是否忽略了不应被忽略的 IP 地址或网段。

      注意，authorized_keys 只保存公钥，不应包含私钥。不要将私钥或完整的敏感配置直接公开。

      第二步：检查 SSH 登录记录

      sudo journalctl -u ssh --since "today" --no-pager


    再检查登录成功记录：

    sudo journalctl _COMM=sshd --since "today" --no-pager

    | grep -E 'Accepted|Failed|Invalid user|session opened'


    检查当前登录用户：

    who

    w


    第三步：检查相关配置文件是否近期被修改

    sudo ls -l --full-time

    /root/.ssh/authorized_keys

    /etc/ssh/sshd_config.d/99-admin-access.conf

    /etc/fail2ban/jail.d/99-admin-ignore.conf


    文件修改时间可以提供线索，但不能证明是谁修改的；读取文件本身通常不会改变其修改时间。

    3. 如何判断风险



    • 低风险迹象： 公钥均为你自己的，配置内容符合预期，没有异常 SSH 登录。

    • 需要调查： 不认识的公钥、异常的 SSH 登录成功记录，或者配置突然发生变化。

    • 高风险迹象： 出现未经授权的登录成功记录、陌生管理员账户、异常 SSH 放行规则，或 Fail2ban 被配置为忽略不可信来源。

      另外，Guest Agent 通常具有较高权限。即使 SSH 日志没有异常，也不能仅凭这一点排除 VPS 管理平台或宿主机管理接口的访问。


    我建议你先把第一步中两个配置文件的内容，以及 SSH 登录记录中 Accepted、Failed 相关行发来。 可以隐藏公网 IP、用户名和公钥内容中的敏感标识，但请保留配置项名称和相关时间。这样可以进一步判断这几条记录更像正常的 VPS 管理操作，还是存在需要处理的安全风险。

    @0-show #0

  • ElonMuskX 10-29 19:03
    11楼

    刚试了一下有几个机器也有

* 帖子来源NodeSeek
附近帖子
返回
飞读
随机推荐