TrustWave 在扫描 CentOS 方面变得更好了——我现在至少可以在提交争议时选择“我有向后移植的软件”。但是他们每个月都需要花费数小时的辛勤指向和点击他们的网站，从而提供出色的工作保障。
现在我的问题。CVE-2016-10009 尚未由 RHEL 人员修补，并且没有可用于 CentOS 的直接修复程序。在 TrustWave 对我最初争议的回应中，有以下说明：
由于这一发现会影响 PCI DSS 合规性，因此确实需要确认它已以某种方式得到解决。扫描报告中列出的要求是升级系统或利用提到的补偿控制（例如永远不要从受信任的白名单（运行时可配置）之外的路径加载 PKCS#11 模块）。
最新的 OpenSSH 补丁已修复向后移植到 OpenSSH 7.3，我不清楚是否会解决此特定漏洞。提到的“补偿控制”——只允许列入白名单的模块——正是 7.4 中的修复，所以这没有帮助，并且扫描报告没有列出任何内容。
因此，我正在寻找可以满足扫描仪的配置更改，但我找不到。 这是对这个问题的一个体面的解释。有什么我可以做的吗？完全禁用 PKCS#11？
我通过在两个 pfSense 防火墙之间建立的 IPSec 隧道连接到办公室中的 QNap NAS（Ubuntu 4.1.2）。这几个月来一直很好。我最近更换了新型号的 NAS 并将固件升级到最新版本。从那时起，当我通过 SSH 连接并运行任何返回多于几行文本的内容时，SSH 连接就会终止。
这意味着它不再响应输入并且终端永远不会超时。回车-~-。序列也不会把它带回来。例如，在根文件夹中运行 ls 工作正常，在 /etc/config 文件夹中运行 ls 将冻结控制台。运行 top 将在大约 20 行后冻结控制台。
我尝试了不同的客户端，这发生在 SecureCRT 和 Putty 上。当我 RDP 进入办公室的 Windows 机器并从那里（在同一子网中）SSH 到 NAS 时，这不会发生，并且相同的命令运行得很好。
我发现了一些提示，这可能与 MTU 相关（例如在这篇文章中），但没有任何结论适用于我的设置。尽管如此，我还是会尝试 MTU 设置，但同时我想也许有人可以提供具体的建议。