如何在 Ubuntu 24.04 中限制 SSH 使用者只能存取特定目錄

在 Ubuntu 24.04 上，限制 SSH 使用者只能存取特定目錄的最安全方法是使用 OpenSSH 的 ` ChrootDirectory--directory` 功能ForceCommand internal-sftp。當帳戶僅需文件傳輸時，這種方法非常理想。它為使用者提供一個 SFTP 視圖，其檔案系統根目錄為您選擇的目錄，同時阻止互動式 shell 和 SSH 轉送。

如果使用者確實需要一個普通的 shell，情況就不同了。 chroot 環境下的互動式 shell 需要它自己的 shell 二進位檔案、函式庫、裝置節點以及 jail 內部的支援檔案。 OpenSSH 文件對此有明確的說明。對於大多數上傳、備份、代理機構、供應商和共享主機帳戶而言，僅支援 SFTP 的 chroot 環境要簡單得多，也更不容易出錯。而對於需要完整命令列環境的非信任使用者來說，容器或專用虛擬機器通常比手動建置 shell chroot 環境更容易維護。

本指南使用 Ubuntu 24.04 LTS 和一個名為 `<username>` 的範例使用者alice。該使用者將被限制在 `<path>` 目錄下/srv/sftp/alice，並且只能在 `<path>` 目錄下寫入資料/files。請根據您的伺服器情況替換名稱和路徑。

開始之前：請了解所有權規則

最常見的 chroot 失敗原因是權限問題。 OpenSSH 要求路徑中的每個組成部分ChrootDirectory都必須由 root 使用者擁有，並且不能被群組或其他使用者寫入。此要求會無條件檢查。這意味著您不應該將路徑設為/srv/sftp/alice可寫入alice。

相反，將 jail 根目錄設為 root 所有，並建立一個可寫入的子目錄：

/srv/sftp/alice        root:root   755
└── files              alice:alice 755

此設計遵循Ubuntu 24.04sshd_config(5)手冊中記錄的行為。手冊指出，internal-sftpchroot 環境內不需要額外的執行時間文件，因此最適合受限的文件傳輸帳戶。

步驟 1：確認 OpenSSH 伺服器已安裝

如有必要，請安裝伺服器軟體包：

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh.service

Ubuntu 官方 OpenSSH 文件使用openssh-server來管理守護程式套件和ssh.service服務。請參閱Ubuntu 伺服器 OpenSSH 指南。

如果這是一台遠端機器，而 SSH 是您唯一的管理途徑，請在進行變更時保持現有管理員工作階段處於開啟狀態。錯誤的 SSH 配置可能會導致您被鎖定。

步驟 2：建立群組並新增受限用戶

建立一個受限使用者群組。如果該群組alice已存在，則僅將她新增至該群組：

sudo groupadd sftpusers
sudo adduser alice
sudo usermod -aG sftpusers alice
id alice

如果您已經在使用 SSH 公鑰，請繼續使用。 chroot 設定控制身份驗證之後的操作；它並沒有要求您從金鑰身份驗證切換到密碼身份驗證。

通常情況下，基於群組的規則比Match User為每個帳戶單獨設定規則更好。它將策略集中在一個地方。當需要將不同使用者限制在不相關的佈局中時，基於使用者的規則仍然有用。

步驟 3：建立一個 root 使用者擁有的 jail 和一個可寫入的子目錄

建立目錄層次結構：

sudo mkdir -p /srv/sftp/alice/files
sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files
sudo chmod 755 /srv/sftp/alice/files

核實所有權：

ls -ld /srv /srv/sftp /srv/sftp/alice /srv/sftp/alice/files
namei -l /srv/sftp/alice

如果/srv`or`/srv/sftp是群組可寫入或使用者可寫入目錄，也需要修復。 OpenSSH 會檢查路徑的所有組成部分，而不僅僅是最終目錄。

步驟 4：在 sshd_config.d 中新增匹配規則

Ubuntu 目前的伺服器文件建議將自訂 SSH 設定保存在單獨的設定檔中，/etc/ssh/sshd_config.d/而不是將其混入打包的主檔案中。建立一個程式碼片段：

sudo nano /etc/ssh/sshd_config.d/90-sftp-restricted.conf

添加：

Match Group sftpusers
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /files
    DisableForwarding yes
    PermitTTY no

Match all

%u展開為已驗證的用戶名，因此alice放置在/srv/sftp/alice。此-d /files參數指示內部 SFTP 伺服器在可寫子目錄中啟動。DisableForwarding yes一條指令即可停用 X11、代理、TCP 和 StreamLocal 轉送；其文件專門用於簡化受限配置。

在程式碼片段中，結尾Match all很重要，因為它會在解析後續配置之前結束條件上下文。

步驟 5：決定採用基於群組的限制還是基於使用者的限制。

對於多個佈局相同的用戶，請保留上述群組規則。對於單一特殊帳戶，請改用用戶專屬區塊：

Match User vendor1
    ChrootDirectory /srv/vendor/vendor1
    ForceCommand internal-sftp -d /incoming
    DisableForwarding yes
    PermitTTY no

Match all

根據管理成本選擇：

步驟 6：重啟前驗證 SSH 配置

編輯文件後切勿立即重新啟動 SSH。請先執行 Ubuntu 推薦的語法測試：

sudo sshd -t

沒有輸出表示語法檢查成功。您也可以查看特定使用者的有效配置：

sudo sshd -T -C user=alice,host=localhost,addr=127.0.0.1   | grep -E 'chrootdirectory|forcecommand|disableforwarding|permittty'

你應該可以看到預期的 chroot 路徑和強制執行的 SFTP 指令。這在 Ubuntu 上尤其有用，因為設定可能來自 `/etc/chroot`/etc/ssh/sshd_config和 `/etc/sftp` 目錄下的檔案/etc/ssh/sshd_config.d/。 Ubuntu 指出，OpenSSH 通常對大多數指令使用第一個取得的值，因此檢查實際生效的設定比假設哪個檔案生效更安全。

步驟 7：重新啟動 SSH 並使用 SFTP 進行測試

應用更改：

sudo systemctl restart ssh.service
sudo systemctl status ssh.service

然後從另一個終端連接：

sftp alice@server.example.com

在 SFTP 內部進行測試：

pwd
ls
put test.txt
ls -l

根據上述配置，初始 SFTP 目錄應該是/files。 SFTP 顯示的斜線是 chroot 的根目錄，而不是真正的伺服器根目錄。

正常的 shell 嘗試不應該產生不受限制的 shell：

ssh alice@server.example.com

因為ForceCommand internal-sftp該帳戶會將請求的會話替換為進程中的 SFTP 伺服器，所以該帳戶特意用於檔案傳輸而不是命令執行。

步驟 8：確認用戶無法逃脫牢籠

嘗試移動到根目錄之上，並檢查敏感主機路徑：

cd ..
ls /
ls /etc
ls /root

在 chroot 環境中，/它代表/srv/sftp/alice主機。如果您在該 jail 內沒有建立任何etc目錄root，則使用者無法存取主機的真實/etc目錄/root。

另外，還要測試上傳操作/files。雖然阻止逃逸但意外地將整個 jail 設定為唯讀的配置是安全的，但對於上傳帳戶來說並不實用。

故障排除：“chroot 目錄的所有權或模式錯誤”

如果登入立即失敗，請檢查 SSH 服務日誌：

sudo journalctl -fu ssh.service

Ubuntu 的 OpenSSH 指南建議使用 SSH 服務日誌進行故障排除。如果遇到所有權或模式錯誤，請檢查每個父目錄：

namei -l /srv/sftp/alice

chroot 路徑必須由 root 使用者擁有，且不能被其他群組或其他使用者寫入。一個常見的錯誤是：

sudo chown alice:alice /srv/sftp/alice

不要透過削弱 OpenSSH 檢查來解決問題。而是將使用者的可寫入區域放在 chroot 根目錄之下：

sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files

如果使用者需要的是 SSH shell 存取權限，而不僅僅是 SFTP 存取權限呢？

ChrootDirectory也可以配合互動式 shell 使用，但設定過程要複雜得多。 OpenSSH 指出，互動式 chroot 至少需要一個 shell 和基本/dev節點，以及允許的命令所需的任何二進位檔案、函式庫、名稱解析檔案和其他依賴項。

對於需要嚴格控制的設備帳戶，建置這樣的隔離環境是合理的。但對於一般的 Linux 命令存取權限，這通常會增加維護負擔：工具和程式庫的安全性更新也必須反映在隔離環境中。如果您的實際需求是“允許此人運行命令，但將其與主機隔離”，那麼容器、虛擬機器或專門建置的受限服務通常更容易進行審計。

值得添加的安全改進

目錄限制只是其中一層。對於面向互聯網的伺服器，還應考慮以下因素：

• 在條件允許的情況下，對人工帳戶和自動化帳戶使用 SSH 公鑰認證。
• 不要給予受限檔案傳輸使用者sudo存取權限。
• 僅供 SFTP 帳號使用DisableForwarding yes，這樣 SSH 連線就不能用於隧道或代理轉送。
• 將可寫入目錄限制在工作流程所需的最小範圍內。
• 新增使用者後，需審核journalctl -u ssh.service文件所有權。
• 測試遠端 SSH 設定變更時，請保持管理員工作階段處於開啟狀態。

ChrootDirectory若要了解`<configuration>`、Match` ForceCommand<configuration>`、`<configuration>` 和 ` <configuration>`的具體行為DisableForwarding，請參閱Ubuntu 24.04 OpenSSH 伺服器設定手冊。有關 Ubuntu 特有的設定佈局、驗證、重新啟動命令和日誌記錄，請參閱Ubuntu OpenSSH 伺服器官方文件。

結論

如果目標是“此 SSH 帳戶只能在單一目錄內上傳和下載檔案”，則使用 root 使用者擁有的目錄ChrootDirectory，將可寫內容放在使用者擁有的子目錄中，並強制執行internal-sftp。重新啟動前進行驗證sshd -t，然後在 chroot 外部測試允許的上傳路徑和嘗試存取。這樣就創建了一個易於理解的小安全邊界，而無需在 chroot 中建立完整的 Linux 環境。