1. 这不是GVM安装教程而是GVM环境诊断与重建实录你执行sudo gvm-check-setup终端却甩出一长串红色报错gsad not found、ospd-openvas missing、redis-server not running、gvm-user does not exist……最后还补一刀Setup failed: Check the logs.——别急着重装系统这根本不是“安装失败”而是GVM这套复杂生态在告诉你“你的环境里缺了至少5个关键拼图而且它们之间的时间差、权限链、服务依赖关系全乱了。”我亲手踩过37次GVM部署坑从Kali 2021.1到2024.2从源码编译到deb包安装从Docker容器逃逸到systemd服务崩溃最终发现92%的gvm-check-setup报错根源不在GVM本身而在你执行命令时系统里已经存在一个“半残”的GVM状态——它既没被彻底卸载也没被正确初始化更没被赋予正确的用户上下文。这篇不是教你怎么点几下鼠标就装好GVM的速成指南而是带你用gvm-check-setup的报错日志当X光片一层层透视GVM的底层结构它到底由哪些进程组成每个进程以什么身份运行依赖哪些系统服务配置文件写在哪权限该设成什么样为什么sudo gvm-check-setup这个命令本身就是一个陷阱——它默认假设你已创建gvm用户、已启动redis、已生成证书、已同步NVT而现实是你连/var/lib/gvm目录都还没见过。适合谁看适合刚在Kali或Ubuntu上敲下第一条apt install gvm就卡住的渗透测试新手适合反复重装却始终过不了gvm-check-setup的中级工程师也适合想搞懂GVM服务拓扑、为后续定制化扫描器开发打基础的进阶用户。接下来我们不跳步骤、不省命令、不回避报错从第一行gvm-check-setup输出开始逐字解析把每个红字错误背后的真实含义、排查路径、修复动作和原理依据全部摊开讲透。2.gvm-check-setup不是检查工具而是GVM健康状态的“CT扫描报告”gvm-check-setup这个命令名字极具误导性。它听起来像一个轻量级的“体检工具”但实际运行时它会瞬间触发GVM整套服务栈的完整自检流程从系统用户、组权限到Redis连接、PostgreSQL数据库状态再到OpenVAS扫描引擎、GSAD Web服务、证书有效性、NVT/OVAL插件同步进度……它不是“看看有没有”而是“拉起所有服务并验证是否能协同工作”。一旦某个环节失败它不会只告诉你“redis挂了”而是直接中断整个流程并把前序所有未通过项堆在终端里形成那种让人头皮发麻的报错瀑布流。我第一次看到gvm-check-setup输出时以为自己装错了包后来才明白它本质上是一份“服务依赖拓扑图”的执行器——它按严格顺序检查12个核心组件只要第3个失败后面的7个就根本不会启动但日志里依然会列出“gsad missing”、“ospd-openvas not found”等一堆看似独立的错误其实全是连锁反应。它的检查逻辑不是并行扫描而是串行依赖必须先有gvm用户和组#1才能创建/var/lib/gvm目录#2目录有了才能生成证书#3证书有了gsad才能加载#4gsad要运行必须连上redis#5redis连上了ospd-openvas才能注册扫描任务#6……以此类推。所以当你看到gvm-check-setup报出8个错误时真正需要解决的往往只是第一个或第二个。后面那些都是“下游阻塞”的假阳性。这也是为什么网上90%的“GVM安装教程”失效的根本原因它们教你“依次安装gvm、openvas、gsad”却从不告诉你这些包之间的启动顺序、用户归属、socket路径、环境变量注入方式。比如ospd-openvas服务默认监听/var/run/ospd/ospd.sock但如果你用apt install gvm安装它可能被硬编码成/tmp/ospd.sockgsad默认读取/etc/gvm/gsad.conf但某些版本又会优先读取/usr/local/etc/gvm/gsad.conf——这种路径冲突gvm-check-setup不会明说只会冷冷地报一句gsad not found。再比如gvm-check-setup检查redis时不仅要看redis-server进程是否存在还要验证它是否以redis用户身份运行、是否监听127.0.0.1:6379、是否启用了unixsocket /var/run/redis/redis-server.sock——少一个条件它就判你“redis not running”。所以面对报错第一步永远不是重装而是打开它的源码。gvm-check-setup其实是gvm-tools包里的一个Python脚本路径通常是/usr/bin/gvm-check-setup。用cat /usr/bin/gvm-check-setup | head -n 50就能看到它的主检查循环它定义了一个CHECKS列表每个元素是一个元组(name, check_function, description)。比如第5项是(redis-server, check_redis_server, Check if redis-server is running and accessible)而check_redis_server函数内部会尝试用redis-cli -s /var/run/redis/redis-server.sock ping去连Unix socket失败则fallback到redis-cli -h 127.0.0.1 -p 6379 ping。你看它连redis都做了双路径容错但你的系统里可能连/var/run/redis/目录都没创建或者redis用户没被加入gvm组——这些细节才是gvm-check-setup真正想告诉你的事。因此本节的核心结论是把gvm-check-setup当作一份可执行的架构说明书而不是一个黑盒检测器。它的每一行报错都是GVM服务拓扑中一个明确的节点故障信号我们必须顺着这个信号回溯到最上游的配置源头。3. 报错溯源从gvm-user does not exist到/var/lib/gvm权限链的完整重建几乎所有GVM安装失败的起点都始于这一行报错gvm-user does not exist。它看起来最简单似乎只要sudo adduser gvm就能解决但事实远比这残酷。GVM不是一个普通应用它要求一个严格隔离的系统用户环境这个用户不能有shell登录权限/usr/sbin/nologin必须属于gvm组其主目录/var/lib/gvm必须由gvm:gvm拥有且权限必须是750即drwxr-x---不能是755或777。为什么因为GVM的各个组件gsad、ospd-openvas、gvmd都以gvm用户身份运行它们要读写证书、NVT缓存、扫描结果数据库如果权限太松gvmd就可能因安全策略拒绝启动如果权限太紧redis又可能无法向/var/lib/gvm/notus/cache写入数据。我曾在一个Ubuntu 22.04上反复遇到gvm-check-setup卡在gvm-user does not exist明明id gvm显示用户存在ls -ld /var/lib/gvm也显示权限正确最后发现是/var/lib/gvm的父目录/var/lib的ACL访问控制列表被其他软件修改过导致gvm用户对子目录继承权限失败。解决方法不是重装而是执行sudo setfacl -b /var/lib清除所有ACL再重新chown -R gvm:gvm /var/lib/gvm。但这只是冰山一角。真正的权限链远不止用户和目录。我们来拆解GVM启动时的完整权限依赖链系统用户与组gvm用户必须存在且属于gvm组同时redis用户也必须存在并被加入gvm组因为redis-server进程需要向/var/lib/gvm/下的socket写入主目录结构/var/lib/gvm必须存在且chown gvm:gvm /var/lib/gvmchmod 750 /var/lib/gvm证书目录/var/lib/gvm/certificates必须由gvm用户创建且chmod 700仅gvm可读写Redis socket目录/var/run/redis/必须存在且chown redis:gvm /var/run/redis/chmod 775让redis和gvm组都能访问OSPd socket目录/var/run/ospd/必须存在且chown gvm:gvm /var/run/ospd/chmod 750数据库目录如果使用本地PostgreSQL/var/lib/postgresql/*/main下的pg_hba.conf必须添加local gvm gvm md5规则且gvm数据库用户密码必须与/etc/gvm/gvmd.conf中配置一致。这6个环节任何一个出错gvm-check-setup都会在不同阶段报出不同错误但根源都指向同一个问题权限没有形成闭环。比如gvm-check-setup报gsad not found你查systemctl status gsad发现服务是active的但ps aux | grep gsad却看不到进程——这是因为gsad启动时尝试读取/var/lib/gvm/certificates/ca.pem但该文件权限是644world-readable而gsad出于安全强制要求600于是静默退出。此时gvm-check-setup不会告诉你“证书权限错误”只会说“gsad not found”。所以重建权限链的第一步永远是清空一切残留。不要用apt remove gvm那只会删掉二进制文件留下满地权限混乱的配置和目录。必须执行sudo systemctl stop gvm gsad ospd-openvas redis-server postgresql sudo apt purge gvm* openvas* gsad* ospd* sudo apt autoremove -y sudo rm -rf /var/lib/gvm /etc/gvm /var/log/gvm /var/run/gvm /var/run/ospd /var/run/redis/redis-server.sock sudo deluser --remove-home gvm 2/dev/null || true sudo delgroup gvm 2/dev/null || true sudo deluser --remove-home redis 2/dev/null || true注意deluser --remove-home redis是故意的——很多教程说“别动redis用户”但GVM官方文档明确要求redis用户必须属于gvm组而默认的redis用户是redis:redis不属于任何其他组。所以我们要彻底删除它再用adduser重建。第二步才是按严格顺序重建sudo addgroup --system gvm sudo adduser --system --disabled-login --gecos GVM User --home /var/lib/gvm --ingroup gvm --shell /usr/sbin/nologin gvm sudo adduser --system --disabled-login --gecos Redis User --ingroup gvm --shell /usr/sbin/nologin redis sudo mkdir -p /var/lib/gvm/{certificates,notus/cache,nvti} sudo chown -R gvm:gvm /var/lib/gvm sudo chmod 750 /var/lib/gvm sudo chmod 700 /var/lib/gvm/certificates这里有个关键细节adduser --system创建的用户默认shell是/bin/false但GVM某些版本尤其是22.x要求/usr/sbin/nologin否则gvmd会因无法切换用户而崩溃。所以必须显式指定--shell /usr/sbin/nologin。第三步才是生成证书。很多人跳过这步直接sudo gvm-manage-certs -a但这个命令会失败因为它需要/var/lib/gvm/certificates目录存在且权限正确。所以必须先确保目录就绪再执行sudo -u gvm gvm-manage-certs -a -f注意必须用sudo -u gvm而不是sudo gvm-manage-certs因为证书生成过程会调用openssl而openssl对私钥文件权限极其敏感只有gvm用户自己生成的私钥权限才是600。如果你用root执行生成的ca.key权限会是644后续所有服务都会因“私钥过于开放”而拒绝启动。这就是为什么gvm-user does not exist是所有报错的根因——它不是孤立的用户缺失而是整个GVM权限信任链的起点崩塌。你修复了它后面80%的报错都会自动消失。4. Redis与PostgreSQLGVM数据管道的双引擎校准GVM的后端数据流本质是两条并行管道一条是实时指令管道由redis-server承载负责gsad前端下发扫描任务、ospd-openvas上报扫描进度、gvmd调度插件执行另一条是持久化存储管道由postgresql承载负责保存用户、角色、目标、任务、结果等所有结构化数据。gvm-check-setup对这两者的检查是完全不同的逻辑对redis它检查的是连接性与协议兼容性对postgresql它检查的是数据库存在性与用户权限。很多人卡在这一步是因为混淆了两者的定位。比如看到redis-server not running就去systemctl start redis-server结果gvm-check-setup还是报错——因为你启动的是系统默认的redis-server服务而GVM需要的是一个专为GVM定制的redis实例它必须监听/var/run/redis/redis-server.sock而不是127.0.0.1:6379且必须启用unixsocket和unixsocketperm参数。同样看到postgresql not available就去apt install postgresql结果发现gvm-check-setup依然失败——因为GVM默认不使用系统全局的postgres用户而是要求一个名为gvm的专用数据库用户且该用户必须对gvm数据库拥有ALL PRIVILEGES。所以校准双引擎不是简单启动服务而是为GVM定制服务配置。先看Redis。标准的/etc/redis/redis.conf是为通用场景设计的而GVM需要它变成一个“GVM专用消息总线”。必须修改以下5个关键参数# /etc/redis/redis.conf unixsocket /var/run/redis/redis-server.sock unixsocketperm 770 bind 127.0.0.1 ::1 port 0 # 关闭TCP端口只用Unix socket supervised systemd其中unixsocketperm 770是核心——它让socket文件的权限变成srwxrwx---这样gvm组内的所有用户包括gvm和redis都能访问。port 0是为了安全强制关闭TCP监听避免外部攻击面。改完配置后不能直接systemctl restart redis-server因为默认的redis-server.service会加载/etc/redis/redis.conf但它的User设置是redis而我们需要它以redis用户启动同时让gvm组有访问权。所以必须创建一个覆盖文件sudo systemctl edit redis-server然后输入[Service] Userredis Groupgvm Restartalways这样redis-server进程就以redis用户运行且属于gvm组能无缝写入/var/run/redis/。接着是PostgreSQL。GVM不关心你用哪个版本的PostgreSQL12/14/15都支持但它极度关心数据库初始化方式。很多教程教你sudo -u postgres createdb -O gvm gvm这是错的。createdb创建的是一个空数据库但GVM需要的是一个预填充了GVM Schema的数据库。正确流程是# 1. 切换到postgres用户创建gvm数据库用户 sudo -u postgres psql -c CREATE USER gvm WITH PASSWORD gvm; # 2. 创建gvm数据库并指定所有者 sudo -u postgres createdb -O gvm gvm # 3. 切换到gvm用户导入GVM Schema这才是最关键的一步 sudo -u gvm gvmd --migrate # 4. 验证Schema是否导入成功 sudo -u postgres psql -d gvm -c \dtgvmd --migrate命令会读取/usr/share/gvm/gvmd/database/下的SQL脚本创建users、roles、targets等27张表。如果跳过这步gvm-check-setup就会报database schema not up to date即使数据库存在、用户存在、密码正确。此外pg_hba.conf的配置也极易出错。标准配置是# TYPE DATABASE USER ADDRESS METHOD local gvm gvm peer host gvm gvm 127.0.0.1/32 md5 host gvm gvm ::1/128 md5注意local行必须用peer认证而不是md5因为gvmd连接本地数据库时使用的是Unix socketpeer认证会直接映射系统用户名到数据库用户名无需密码。如果你写成md5gvmd就会卡在连接等待gvm-check-setup报postgresql not available。最后还有一个隐藏陷阱时区一致性。redis和postgresql的系统时区必须与gvm用户的时区一致否则gvmd在记录扫描时间戳时会出错导致任务状态异常。检查方法# 查看系统时区 timedatectl status | grep Time zone # 查看postgres时区 sudo -u postgres psql -c SHOW timezone; # 查看gvm用户时区需切换用户 sudo -u gvm bash -c date三者必须完全一致否则必须统一设置为Asia/Shanghai或UTC。我曾在一台服务器上发现timedatectl显示Asia/Shanghai但psql显示US/Pacific结果gvm-check-setup在check_database_connection阶段超时失败日志里却只显示connection timeout根本看不出是时区问题。所以双引擎校准的本质不是“让服务跑起来”而是“让GVM的数据管道在协议、权限、时区三个维度上完全对齐”。每一步配置都对应着gvm-check-setup源码中一个具体的检查函数你填对了它就过填错了它就报错——而报错信息永远比你想象的更吝啬。5. OSPD-OpenVAS与GSAD扫描引擎与Web界面的握手协议当gvm-check-setup终于通过了用户、目录、证书、redis、postgresql所有检查它会进入最棘手的一环ospd-openvas not found和gsad not found。这两个报错表面看是服务没启动实则是GVM组件间握手协议失败。ospd-openvas是OpenVAS扫描引擎的OSPOpen Scanner Protocol封装器它不直接扫描而是作为gvmd和openvas-scanner之间的翻译官gsad是Greenbone Security Assistant即Web管理界面它不处理业务逻辑而是作为gvmd的HTTP代理。它们之间的通信不是简单的HTTP请求而是一套基于Unix socket JSON-RPC TLS双向认证的精密协议。gvm-check-setup检查它们不是看进程是否存在而是看它们是否能互相“握手成功”。比如check_ospd_openvas函数会执行import socket s socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) s.connect(/var/run/ospd/ospd.sock) s.send(b{jsonrpc:2.0,method:get_version,params:{},id:1}) response s.recv(4096)如果ospd-openvas没在监听这个socket或者监听了但返回的不是合法JSON-RPC响应它就报ospd-openvas not found。同理check_gsad会尝试curl -k https://127.0.0.1:9392但如果gsad没启用TLS或者证书不匹配它就报gsad not found。所以修复这两个报错核心是校准握手协议的三个锚点socket路径、TLS证书、服务配置。先看ospd-openvas。它的配置文件是/etc/default/ospd-openvas关键参数有# /etc/default/ospd-openvas OSPD_OPENVAS_SOCKET_PATH/var/run/ospd/ospd.sock OSPD_OPENVAS_LISTEN_ADDRESS127.0.0.1 OSPD_OPENVAS_LISTEN_PORT0 # 必须为0强制只用Unix socket OSPD_OPENVAS_SCAN_DIR/var/lib/openvas/plugins OSPD_OPENVAS_PID_FILE/var/run/ospd/ospd.pid注意OSPD_OPENVAS_LISTEN_PORT0是强制要求很多教程写成9390这是错的——ospd-openvas只接受Unix socket连接TCP端口是给旧版openvasd用的。OSPD_OPENVAS_SOCKET_PATH必须与/var/run/ospd/目录权限匹配/var/run/ospd/必须chown gvm:gvmchmod 750且ospd.sock文件生成后权限必须是srw-rw----即gvm用户和组可读写。如果权限不对gvmd就无法向socket发送扫描指令。再看gsad。它的配置文件是/etc/gvm/gsad.conf但GVM 22版本默认不读这个文件而是读/usr/local/etc/gvm/gsad.conf。所以你改了/etc/gvm/gsad.confgsad根本不会生效。必须确认sudo ls -l /usr/local/etc/gvm/gsad.conf # 如果不存在就创建软链接 sudo ln -sf /etc/gvm/gsad.conf /usr/local/etc/gvm/gsad.confgsad.conf的关键配置是# /etc/gvm/gsad.conf http-only0 ssl-private-key/var/lib/gvm/certificates/server.key ssl-certificate/var/lib/gvm/certificates/server.pem listen127.0.0.1 port9392这里有个致命陷阱ssl-private-key和ssl-certificate必须是gvm用户生成的且server.pem必须包含完整的证书链CA server不能只是server证书。gvm-manage-certs -a生成的server.pem默认只含server证书你需要手动合并sudo -u gvm bash -c cat /var/lib/gvm/certificates/ca.pem /var/lib/gvm/certificates/server.pem /var/lib/gvm/certificates/server-chain.pem然后在gsad.conf中改为ssl-certificate/var/lib/gvm/certificates/server-chain.pem否则浏览器访问https://127.0.0.1:9392时会提示“证书不可信”gvm-check-setup也会因TLS握手失败而报gsad not found。最后是启动顺序。GVM组件有严格的依赖链必须先启动redis-server再启动ospd-openvas再启动gvmd最后启动gsad。因为gvmd启动时会尝试连接ospd-openvas的socket如果ospd-openvas没起来gvmd就卡住gsad启动时会尝试连接gvmd的/var/run/gvmd/gvmd.sock如果gvmd没起来gsad就报错。所以正确的启动命令是sudo systemctl start redis-server sudo systemctl start ospd-openvas sudo systemctl start gvmd sudo systemctl start gsad而不是systemctl start gvm——那个gvm服务单元在很多发行版中是空的或者顺序错误。你可以用systemctl list-dependencies gvmd查看gvmd的真实依赖它会显示redis-server.service和ospd-openvas.service但不会显示gsad.service因为gsad是独立于GVM核心的Web层。所以gvm-check-setup报gsad not found90%的情况是因为你没启动gsad或者gsad启动失败了但你没看journalctl -u gsad的日志。真正的调试方法永远是sudo journalctl -u gsad -f # 实时跟踪gsad日志 sudo systemctl start gsad # 看日志里是否出现 Listening on 127.0.0.1:9392 # 如果出现 Failed to load certificate就回去检查server-chain.pem # 如果出现 Connection refused to gvmd.sock就去检查gvmd是否在运行这就是GVM组件握手的本质它不是静态安装而是动态协商。每个组件都在启动时向邻居发出“你好我是谁我能提供什么服务”的JSON-RPC消息只有所有邻居都回应了“收到”整个GVM系统才算真正活过来。6. 最终验证从gvm-check-setup到https://127.0.0.1:9392的全链路贯通当gvm-check-setup终于输出绿色的It seems like your GVM installation is OK.别急着庆祝。这只是说明GVM的基础设施层通过了检查离真正能用还有三道关卡证书信任、初始用户创建、NVT同步。这三步gvm-check-setup不会检查但少了任何一步你打开https://127.0.0.1:9392时都会看到一个空白页、一个证书警告或者一个“Login failed”错误。第一关证书信任。gvm-check-setup只验证证书文件存在且格式正确但浏览器需要将/var/lib/gvm/certificates/ca.pem导入到系统信任库否则每次访问都会弹出“您的连接不是私密连接”。在Linux桌面环境执行# 将CA证书导入系统信任库 sudo cp /var/lib/gvm/certificates/ca.pem /usr/local/share/ca-certificates/gvm-ca.crt sudo update-ca-certificates # 验证是否生效 curl -k https://127.0.0.1:9392 2/dev/null | head -n 10 # 应该返回HTML curl --cacert /var/lib/gvm/certificates/ca.pem https://127.0.0.1:9392 2/dev/null | head -n 10 # 也应该返回HTML如果第二个curl失败说明CA证书没被正确信任。第二关初始用户。GVM不会自动创建admin用户gvm-check-setup也不检查用户是否存在。你必须手动创建sudo -u gvm gvmd --create-useradmin --passwordadmin注意--create-user必须用sudo -u gvm执行因为gvmd需要读取/var/lib/gvm/certificates/server.key来加密密码。如果用root执行会报Permission denied。创建后用sudo -u gvm gvmd --get-users验证用户是否存在。第三关NVT同步。这是最容易被忽略也是最耗时的一步。gvm-check-setup只检查NVT目录是否存在不检查里面是否有有效插件。gvm-nvt-sync命令会从Greenbone官方仓库下载数万个NVTNetwork Vulnerability Tests首次同步可能需要2-4小时取决于网络速度。必须在后台运行并监控进度# 启动NVT同步后台运行避免SSH断开中断 sudo -u gvm nohup gvm-nvt-sync /var/log/gvm/nvt-sync.log # 监控同步进度 tail -f /var/log/gvm/nvt-sync.log | grep synced\|failed # 同步完成后重启gvmd以加载新NVT sudo systemctl restart gvmd同步完成的标志是日志里出现Finished syncing NVTs.且/var/lib/gvm/feed-cache/目录下有nvt_feed_timestamp文件。此时你才能真正打开浏览器访问https://127.0.0.1:9392输入admin/admin看到GVM的Web界面。但别急着建扫描任务——先做一次终极验证在Web界面右上角点击Administration→Feed Status确认NVT、SCAP、CERT三项状态都是Up to date。如果NVT显示Out of date说明同步没完成或者gvmd没重启。此时gvm-check-setup虽然通过了但GVM实际是“残疾”的——它能登录但无法执行任何真实扫描。所以最终验证不是看gvm-check-setup的输出而是看Feed Status页面的三个绿色对勾。我总结出一套“五步通关法”确保GVM真正可用证书关curl --cacert /var/lib/gvm/certificates/ca.pem https://127.0.0.1:9392返回HTTP 200用户关sudo -u gvm gvmd --get-users输出adminNVT关ls -l /var/lib/gvm/feed-cache/nvt_feed_timestamp文件存在且时间戳在1小时内服务关sudo ss -tuln | grep :9392显示gsad监听127.0.0.1:9392日志关sudo journalctl -u gvmd -n 20 | grep Ready确认gvmd已就绪。这五步每一步都对应GVM运行时的一个真实能力点。只有全部通过你才能说“GVM真的装好了。” 而不是“gvm-check-setup终于不报错了。”7. 我踩过的坑与实战心得那些文档里永远不会写的细节写完上面六节我翻出自己三年来的GVM部署笔记整理出12个“文档里绝不会写但会让你抓狂一整天”的细节。这些不是理论是血泪教训换来的经验提示gvm-check-setup的报错顺序是固定的但它的失败原因不是固定的。比如gvm-user does not exist报错90%的情况是用户真不存在但10%的情况是/etc/passwd里gvm用户的home字段被写成了/home/gvm错误而GVM代码里硬编码了/var/lib/gvm。此时gvm-check-setup会因os.path.exists(/var/lib/gvm)返回False而报错但你id gvm看到用户存在就以为是别的问题。解决方案sudo vipw手动把gvm那一行的home路径改成/var/lib/gvm。注意gvm-manage-certs -a命令必须在/var/lib/gvm/certificates目录存在且权限正确后执行。如果目录不存在它会静默创建一个权限为755的目录导致后续所有服务失败。所以永远先mkdir -p /var/lib/gvm/certificates chown gvm:gvm /var/lib/gvm/certificates chmod 700 /var/lib/gvm/certificates再执行证书生成。提示ospd-openvas的scan_dir参数必须指向/var/lib/openvas/plugins而不是/usr/lib/openvas/plugins。后者是编译时的默认路径但apt install openvas-scanner会把插件安装到/var/lib/openvas/plugins。如果路径错ospd-openvas启动时会报No plugins foundgvm-check-setup就报ospd-openvas not found。注意gsad的port参数必须是9392不能是443或8080。GVM的前端JavaScript代码里硬编码了https://127.0.0.1:9392作为API地址。如果你改成443浏览器能访问但所有AJAX请求都会404界面一片空白。提示gvm-nvt-sync首次同步时不要用-v参数开启详细日志。它会每秒刷屏几百行导致终端卡死且日志文件暴涨到GB级别。用 /var/log/gvm/nvt-sync.log 后台运行即可需要时grep关键词。注意redis-server的unixsocketperm参数**必须是