例如，当连接到 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，我想使用单个用户根据委派对不同目录的访问权限来完成此操作到每个键。
答案1
仅具有-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
如果您打算进行实际的 chroot，则应该非常仔细地阅读该选项的描述ChrootDirectory：对用作目录的要求ChrootDirectory非常严格。
不幸的是，您似乎无法使用密钥来确定会话将被 chroot 到的目录：尽管该ChrootDirectory选项接受一些 %-tokens，最新版本 OpenSSH 的 sshd_config(5) 手册页说：
ChrootDirectory 接受标记 %%、%h、%U 和 %u。
这四个标记分别表示：文字%字符、用户的主目录、数字用户 ID 和用户名。
例如，如果您的目标是让 Python 应用程序为多个客户准备文件，那么这就是用户组的用途！在许多现代 Linux 发行版上，每个用户都与专用于该用户的组一起创建，组名称等于用户名。
您可以这样设置您的用户帐户：
| 用户 | 小学组 | 次要团体 |
|---|---|---|
| 蟒蛇应用程序 | 蟒蛇应用程序 | 测试1，测试2，测试3... |
| 测试1 | 测试1 | （没有任何） |
| 测试2 | 测试2 | （没有任何） |
| 测试3 | 测试3 | （没有任何） |
| ... | ... | ... |
如果test1、test2等test3用户的主目录设置的权限至少为 710 ( drwx--x---)，并且每个主目录都有一个权限为 2770 ( ) 的组可写子目录drwxrws---，则用户pythonapp将有权访问所有这些组可写的子目录子目录，但用户test...将无法访问彼此的主目录，也无法访问其中的组可写目录，因为用户之间不存在公共组成员身份test...。组可写子目录上的 setgid 位将确保用户创建的任何文件pythonapp都将分配给特定于用户的组，因此test...用户永远不会看到该pythonapp组的名称。
当然，如果您有成百上千的客户，这种方法可能很难扩展到那么远。