openssh/sftp-server 虛擬 chroot 不起作用
例如，當連接到 ssh 並執行時，
/usr/libexec/openssh/sftp-server -d /opt/files可以從 sshfs 連接獲取/根目錄。例如：有一個
test使用者和來自authorized_keys有兩個訪問權限，一個具有所有訪問權限，另一個具有有限訪問權限，例如：restrict,command="/usr/libexec/openssh/sftp-server -d /opt/files" ssh-rsa AAA...但是用這個鍵可以掛載根目錄：
# mkdir /mnt/remote # sshfs test@hostname:/ /mnt/remote # ls /mnt/remote bin boot dev etc home ...我正在嘗試與在 python 中開發的自定義軟體創建集成，這就是為什麼我嘗試使用單個使用者而不是使用不同的使用者和不同的權限進行 chroot，我想使用單個使用者來根據委派對不同目錄的訪問權限來做到這一點到每個鍵。
僅具有
-d選項sftp-server不會導致會話被 chroot。
sftp-server它本身沒有特殊權限，並且chroot()系統呼叫需要 root 權限（或特定CAP_SYS_CHROOT功能，如果正在使用單獨的功能）。所以實際上不可能sftp-server執行實際的 chroot 操作，除非它以 root 身份執行。
sftp-server(8)手冊頁說：-d 開始目錄
為使用者指定一個備用起始目錄。
$$ … $$預設是使用使用者的主目錄。此選項與 sshd_config(5) ChrootDirectory 選項結合使用時很有用。
因此，您
sftp-server -d /opt/files不是“虛擬 chroot”。這只不過是cd /opt/files在將 SFTP 會話的控制權交給遠端客戶端之前。要僅對一個特定使用者進行 chroot，您可以在
/etc/ssh/sshd_config文件末尾執行以下操作：Match User test ChrootDirectory /opt/files如果您打算進行實際的 chrooting，則應
ChrootDirectory仔細閱讀該選項的說明：使用的目錄要求ChrootDirectory非常嚴格。不幸的是，您似乎無法使用密鑰來確定會話將被 chroot 到的目錄：儘管該
ChrootDirectory選項接受一些 %-tokens，但即使是最新版本的 OpenSSH 的 sshd_config(5) 手冊頁也說：ChrootDirectory 接受標記 %%、%h、%U 和 %u。
這四個標記分別表示：文字
%字元、使用者主目錄、數字使用者 ID 和使用者名。如果您的目標是讓 Python 應用程序為多個客戶準備文件，那麼這就是使用者組的目的！在許多現代 Linux 發行版上，每個使用者都與一個專用於該使用者的組一起創建，組名與使用者名相同。
您可以這樣設置您的使用者帳戶：
如果
test1,test2等test3使用者的主目錄設置了至少 710 (drwx--x---) 的權限，並且每個主目錄都有一個權限為 2770 (drwxrws---) 的組可寫子目錄，則使用者pythonapp將有權訪問所有這些組可寫子目錄，但test...使用者將無法訪問彼此的主目錄，也無法訪問其中的組可寫目錄，因為test...使用者之間沒有共同的組成員資格。組可寫子目錄上的 setgid 位將確保pythonapp使用者創建的任何文件都將分配給特定於使用者的組，因此test...使用者甚至永遠不會看到pythonapp組的名稱。當然，如果您有成百上千的客戶，這種方法可能很難擴展到那麼遠。