☰

AIX 6.1 SFTP：允许 chroot 用户访问其家外的文件

tag-icon • tag-icon sftp chroot aix
AIX 6.1 SFTP：允许 chroot 用户访问其家外的文件

第一次发帖比较冗长，我尽量简洁地提供详细信息。

我正在 AIX 6.1 服务器上工作，其中 SFTP（通过 WinSCP）已被多个服务帐户使用来访问许多子目录中的文件/app/data。

我被要求设置一个 SFTP 用户帐户以允许访问两个子目录/app/data/bills& /app/data/invoices，但它不能访问其他子目录或服务器上的任何其他地方。我无权更改目录分支内的任何所有者、组或权限/app。

点击此链接 -配置 sftp chroot 环境- 我已经成功创建了一个具有主目录的帐户，/sftpjail/sftpuser并已确认 a) 它不能通过其他方法（SSH、控制台）登录，并且 b)能通过 WinSCP 连接，只能看到其主目录的内容。

  • 我的/etc/ssh/sshd_config部分如下：
Match Group sftpgrp
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
        PermitTunnel no
        X11Forwarding no

  • 该分支下的目录和文件/app/data均归该组所有appsuser且属于该组appsgroup，权限为 775（ug=rwx,o=rx）。

  • sftpuser帐户也是该组的成员appsgroup。

我已经在用户主目录中创建了符号链接/app/data/bills，我认为这不起作用，因为该链接是指向 chroot 之外目录的路径。

我已尝试将/app/data/bills目录挂载到用户主目录中的挂载点：

cd /sftpjail/sftpuser
mkdir bills
mount /app/data/bills bills

...后一种方法产生了一些有趣的结果：

  • 我可以通过 WinSCP 连接并查看bills目录，如果我双击它，那么我会出现一个错误对话框，当清除后，我会“进入”目录但无法看到任何内容。

  • 如果我sftp sftpuser@localhost从 AIX 服务器使用，它会让我bills毫无问题地导航到目录，但ls内容之一会给出remote readdir("/bills"): Failure消息。
    我能够进一步导航到/bills/2019和/bills/2019/09子目录，每次都会ls产生相同的错误。然而，当我将临时文件放入时，
    事情变得非常有趣，它不仅成功上传了文件，而且在上传之后它还可以工作。当我删除临时文件后，它又回到了错误状态，文件恢复并再次工作。put/billslsputls

问题 1：是否可以访问 chroot home 之外的目录，如果可以，如何访问？

问题 2：还有其他方法可以达到所需的结果吗？不需要安装第三方软件的方法。

如果您已经读到这里，我非常感谢您的耐心。

答案1

符号链接本质上只是指向另一个文件的指针，但您不能指向 chroot 之外的某个东西，因为它会寻找 chroot 内不存在的同名文件。

您可以使用mountwithbind重新挂载监狱中所需的目录。

例如：

# mount --bind /bin /chroot/bin
# mount --bind /lib /chroot/lib
# chroot /chroot

如果您希望将其放入/etc/fstab，则相同示例如下：

/bin /chroot/bin none bind
/lib /chroot/lib none bind

答案2

正如@harrymc 的评论中提到的，我以为我已经找到了使用“namefs”挂载类型的答案，但是即使它允许 SFTP 会话导航到挂载点，“ls”命令也显示它为空（事实并非如此）。

我的团队领导是个非常聪明的人，他建议可能需要在源目录中放置一个点文件才能进行浏览，所以我创建了一个“.do-not-delete”文件，然后，嘿，Presto！它成功了。但是（我敢打赌，你知道这会发生）... 它需要在用户需要浏览的每个子目录中放置一个点文件，如果经常创建新的子目录，那么这实际上不可持续。

进一步的测试表明，点文件的存在会产生混合且不可预测的结果，例如，在 SFTP 会话中，我删除了一个临时文件，然后发现我无法再浏览目录。当我从单独的 SSH 会话中删除点文件时，浏览功能又恢复了。我最终发现了几乎所有存在或缺少点文件以及浏览能力或不浏览能力的组合。

此时，由于不可预测的行为，再加上操作系统和 SFTP 包的老化，以及缺乏任何可行的升级途径，决定这不是一个可行的解决方案，请求此访问的团队需要重新开始。

感谢 harrymc 的“绑定”建议以及所有花时间阅读本文的人。

干杯，

缺口

PS：我很高兴这个问题得以解决。

相关内容