負載測試 vsftpd 導致來自 unix_chkpwd 的高 CPU 負載
我正在研究用 vsftpd（通過 TLS）替換 samba 文件共享的概念證明。這不是公共文件儲存，因此對安全性的需求至關重要。並且客戶端只會寫入此位置以供伺服器接收並處理。
但是當我開始使用 JMeter 對 FTP 部分進行負載測試時遇到了一些問題。負載測試場景是每個使用者使用本地帳戶連接並登錄，上傳一個小文件，註銷，然後等待一秒鐘。
它適用於大約 300 個使用者。在那之後，問題開始表現為
unix_chkpwd每幾秒鐘的波波開始導致大量 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 左右。考慮到我在伺服器上的低負載，它仍然有點高，但它給了我選擇。
這可能是由於密碼散列的成本。
/etc/shadow未加密，它包含由合適的密碼散列函式派生的密碼散列。現代系統使用高級散列函式，故意使計算成本高昂，以阻止密碼猜測攻擊。查看
/etc/shadow並檢查第二個欄位的前幾個字元。可能會有一個前綴$6$或$y$其他帶有美元符號的前綴。這決定了散列函式，看看man 5 crypt前綴是什麼意思。如果受影響的帳戶使用昂貴的散列函式，請考慮切換到更便宜的散列函式（或者如果您使用現代可調函式，則調整散列參數）以獲得所需的吞吐量。然後確保該帳戶使用一個非常長的隨機密碼，這樣就不必擔心對暴力破解的抵抗力。
或者，您可以考慮為 FTP 部署客戶端證書 TLS 身份驗證，而不是使用密碼（特別是如果您已經使用 TLS 來保護傳輸中的數據）。