我正在研究用 vsftpd（通过 TLS）替换 samba 文件共享的概念验证。这不是公共文件存储，因此安全性至关重要。客户端只会写入此位置，以便服务器接收和处理。
但是当我开始使用 JMeter 对 FTP 部分进行负载测试时，我遇到了一些问题。负载测试场景是每个用户连接并使用本地帐户登录，上传一个小文件，注销，然后等待一秒钟。
最多可容纳 300 名左右的用户，它可以正常工作。在那之后，问题开始显现，unix_chkpwds 波开始导致每隔几秒出现大量 CPU 峰值，然后在一分钟左右后变成恒定负载。在 16 个逻辑核心系统上，平均负载显示在 60-80 之间。我觉得解密和读取影子文件不应该成为这么大的负担。
目前/etc/pam.d/vsftpd配置为：
auth required pam_succeed_if.so user = citsl_ftp
auth required pam_unix.so
account sufficient pam_permit.so
启用匿名登录或编辑/etc/pam.d/vsftpd为不使用pam_unix.so模块进行身份验证可以“修复”该问题。我确保进程数量没有超出上限，ps -A --no-header | wc -l仅显示大约 400-800 个进程。但我也注意到进程的 PID 上升得很快，并且每 10 秒左右就循环一次（这看起来有点令人担忧，但我对 Linux 的了解不够，无法判断这是否是一个实际问题）。
我在学习过程中学到了很多东西，所以如果我是个傻瓜，请告诉我 FTP 对于私有只写文件存储来说是错误的工具。但unix_chkpwd在这种情况下，行为是否符合您的预期，还是我错过了什么？使用受密码保护的本地用户是否是错误的方式？如果我使用高度限制的匿名登录，我会让自己变得多么脆弱？
编辑：正如 TooTea 怀疑的那样，罪魁祸首是密码的哈希算法。将其从使用 SHA-512 更改为 md5 将平均 CPU 使用率降低到 9 左右。考虑到我在服务器上施加的低负载，这对我来说仍然有点高，但它给了我选择。
答案1
这可能是由于密码散列的成本造成的。/etc/shadow未加密，它包含由适当的密码散列函数导出的密码散列。现代系统使用先进的散列函数，这些函数的计算成本故意较高，以阻止密码猜测攻击。
查看/etc/shadow并检查第二个字段的前几个字符。可能会有一个前缀，如$6$或$y$或其他带有美元符号的东西。这决定了哈希函数，看一下man 5 crypt前缀的含义。
如果受影响的帐户使用昂贵的哈希函数，请考虑切换到更便宜的哈希函数（或者如果您使用现代可调函数，则调整哈希参数）以获得所需的吞吐量。然后确保该帐户使用非常长的随机密码，这样就不会出现暴力破解的问题。
或者，您可以考虑为 FTP 部署客户端证书 TLS 身份验证，而不是使用密码（特别是如果您已经使用 TLS 来保护传输中的数据）。