我是 Linux 新手。
我正在使用 Redhat 5.5 伺服器，並使用基於 Java 的 SFTP 腳本，該腳本允許多個使用者將文字檔案上傳到伺服器。我尚未決定是否每個使用者都有一個單獨的目錄，或者是否使用包含其客戶 ID 的命名約定。
這些檔案包含一些有關其 LAN 設定的個人信息，因此我更喜歡使用 SFTP 而不是 FTP。據我了解，SFTP 是加密的（另外，我有一個 Java 類別配置為透過 SFTP 上傳，所以我不喜歡切換協議，除非它們有一個很好的理由）。
該原型適用於支援大量客戶的系統，透過命令列不斷添加和刪除客戶端的想法似乎非常不切實際。 （再次強調，我是 Linux 和 Redhat 的新手）。
授予多個使用者使用唯一的使用者名稱和密碼上傳檔案的 SFTP 權限的正常約定是什麼。
答案1
您可以透過將外部 sshd 設定為 chrooted sftpd 來完成此操作（為此使用 sshd_config 中的 sftpd-internal 選項）。每個使用者都可以有自己的 chroot-jail。在使用者的authorized_key 檔案上（不允許密碼！），您應該為每個公鑰添加禁止 shell 存取的必要前綴。您的 chroot 還應該只包含 sftp 訪問的基本設定（沒有二進位文件，沒有庫，只有 /dev/null、/dev/zero、/dev/random 和 /dev/urandom - 據我所知）。
答案2
你所描述的是可能的，但這可能不是最好的想法，特別是如果你，正如你所說，是 Linux 新手。
正如您所說，管理檔案權限和使用者將是一場噩夢，而 SFTP 需要 SSH，SSH 本身可以公開各種功能，例如在遠端伺服器上執行程式碼和下載檔案。
它是可以配置具有一定安全性的 SFTP 伺服器，但配置過程中存在許多陷阱。網路上有許多關於使用 SSHd 配置僅 SFTP 使用者的誤導性建議。長話短說，就是不是足以簡單地將他們的登入 shell 更改為無效 shell，您還需要擔心他們繞過 shell 遠端執行命令的能力，以及他們讀取主目錄之外的潛在敏感系統檔案的能力，以及他們使用SSH 隧道繞過防火牆。以及任何其他功能，我可能一時記不起。
還有它是可以繞過整個「需要為每個客戶創建一個用戶」的事情，可以透過使用 PAM 進行一些黑暗魔法讓 SSH 針對其他用戶資料庫進行身份驗證，或者透過簡單地共享單一用戶帳戶（這應該足夠長了）因為你只關心讓用戶上傳文件）。
此外，您還將以某種方式解決 SFTP 在您的應用程式中存在的基本安全問題，其中許多遠端使用者需要能夠驗證遠端伺服器是否是看起來的那個。 SSH 沒有憑證授權單位 - SSH 用於防止中間人攻擊的方法是快取用戶端連接到的伺服器的 SSH 伺服器金鑰的指紋，並且該金鑰是否與先前看到的金鑰匹配， 一切都很好。然而如果密鑰未知，由於這是客戶端第一次連接，SSH需要使用者手動檢查指紋。期望你的客戶真正這樣做是不合理的，幾乎每個人都會點擊“是”，因為他們想繼續他們的生活。您也許可以將有效的主機指紋與您的應用程式一起分發，但這似乎有點像一場噩夢。
如果您確實決定繼續使用 SFTP，儘管存在描述的潛在問題，我還是建議您進行調查RSSH限制使用者只能使用 SFTP。此外，您應該將所有 SFTP 使用者保留在 chroot 監獄中，這樣他們就無法幹擾伺服器的操作或存取任何系統檔案。 （即使如此，攻擊者也有可能列舉您系統的使用者...）而且您還需要確保 sshd 配置為封鎖來自 SFTP 使用者的 SSH 隧道。
…
與其處理這種混亂，我建議考慮使用另一種協議來上傳文件，這似乎更適合您的用例 - 為什麼不考慮使用 HTTPS 上傳文件？您需要某種伺服器端 CGI 腳本或 Java servlet 或其他東西來接收檔案並對它們執行一些有用的操作並執行身份驗證。伺服器端腳本可以負責將檔案儲存在有用的位置。至於客戶端問題，透過 HTTPS 上傳檔案是一件很常見的事情，如果沒有一些可以輕鬆使用的現成 API 類，我會感到驚訝檔案上傳。
當然，這意味著您必須實際編寫一些伺服器端CGI 腳本來處理您的問題，但我確實懷疑您無論如何都會想要以某種方式以程式設計方式處理傳入的文件，這實際上使它更容易，因為程式碼每次有新檔案時都會為您呼叫。