令人沮丧的是，SFTP 用户突然无法连接到我的 Amazon Linux 服务器。
/var/log/secure 显示以下错误：
sshd[7291]: fatal: safely_chroot: stat("/chroot/uhleeka"): Permission denied [postauth]
/var/log/安全：
==> /var/log/secure <==
Nov 21 23:49:23 amzl-lamp sshd[7291]: Accepted password for uhleeka from 172.31.0.254 port 47170 ssh2
Nov 21 23:49:24 amzl-lamp sshd[7291]: pam_unix(sshd:session): session opened for user uhleeka by (uid=0)
Nov 21 23:49:24 amzl-lamp sshd[7291]: fatal: safely_chroot: stat("/chroot/uhleeka"): Permission denied [postauth]
Nov 21 23:49:24 amzl-lamp sshd[7291]: pam_unix(sshd:session): session closed for user uhleeka
SSHD 的调试输出：
$ /usr/sbin/sshd -ddd -p 33333
...
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug3: PAM: opening session
debug1: monitor_reinit: /dev/log doesn't exist in /chroot/%u chroot - will try to log via monitor using [postauth] suffix
User child is on pid 6655
debug1: PAM: establishing credentials [postauth]
debug3: safely_chroot: checking '/' [postauth]
debug3: safely_chroot: checking '/chroot/' [postauth]
debug3: safely_chroot: checking '/chroot/uhleeka' [postauth]
safely_chroot: stat("/chroot/uhleeka"): Permission denied [postauth]
debug1: do_cleanup [postauth]
debug3: PAM: sshpam_thread_cleanup entering [postauth]
debug3: mm_request_send entering: type 124 [postauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 124
debug3: mm_request_receive entering
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials
debug3: PAM: sshpam_thread_cleanup entering
SELinux 已禁用：
$ sestatus
SELinux status: disabled
$ ls -lZ /chroot/uhleeka/
drwxr-x--- root root ? .
drwx--x--- root sftp-only ? ..
drwx--x--- root sftp-only ? etc
drwxr-xr-x root sftp-only ? home
没有发生任何配置更改或权限更改，但昨天运行了 yum update：
$ rpm -qa --last
system-release-2016.09-0.8.noarch Mon 21 Nov 2016 04:34:40 PM UTC
cloud-init-0.7.6-2.14.amzn1.noarch Mon 21 Nov 2016 04:34:40 PM UTC
python26-botocore-1.4.74-1.60.amzn1.noarch Mon 21 Nov 2016 04:34:39 PM UTC
openssh-server-6.6.1p1-31.62.amzn1.x86_64 Mon 21 Nov 2016 04:34:39 PM UTC
openssh-clients-6.6.1p1-31.62.amzn1.x86_64 Mon 21 Nov 2016 04:34:39 PM UTC
aws-cli-1.11.17-1.43.amzn1.noarch Mon 21 Nov 2016 04:34:39 PM UTC
python27-botocore-1.4.74-1.60.amzn1.noarch Mon 21 Nov 2016 04:34:38 PM UTC
bind-utils-9.8.2-0.47.rc1.51.amzn1.x86_64 Mon 21 Nov 2016 04:34:38 PM UTC
bind-libs-9.8.2-0.47.rc1.51.amzn1.x86_64 Mon 21 Nov 2016 04:34:38 PM UTC
openssh-6.6.1p1-31.62.amzn1.x86_64 Mon 21 Nov 2016 04:34:37 PM UTC
...
关于 openssh 更新：https://alas.aws.amazon.com/ALAS-2016-770.html
我们发现 OpenSSH sshd 守护进程在运行登录程序之前获取了 PAM 环境设置。在 UseLogin=yes 的配置中，pam_env PAM 模块配置为读取用户环境设置，本地用户可以利用此漏洞以 root 身份执行任意代码。
/etc/ssh/sshd_config 包含：
UsePAM yes
#UseLogin no
#PermitUserEnvironment no
最新的更新似乎是最有可能的罪魁祸首。是否存在配置问题，导致只有 chroot 用户突然无法使用最新的 openssh 进行访问？
答案1
编辑：这个问题应该在 openssh-6.6.1p1-32.el7 中修复 https://bugzilla.redhat.com/show_bug.cgi?id=1398569
OpenSSH-6.6.1p1-31 更新后，在尝试 SFTP 连接时，只会检查用户的主要组以进行身份验证。如果 root 和用户的主要组拥有主目录且至少有 710 个权限，则连接尝试应该会成功。
重现步骤：
$ 组 sftpuser sftpuser：sftp 组 sftpuser $ ls -ld /home/sftpuser/ drwx--x--- 2 root sftpuser 4096 11月22日 18:31 sftpuser/ $ sftp sftpuser@localhost sftpuser@localhost 的密码： 写入失败：管道损坏 无法读取数据包：对端重置连接 $ chgrp sftpgroup sftpuser/ $ ls -ld /home/sftpuser/ drwx--x--- 2 root sftpgroup 4096 11月22日 18:31 sftpuser/ $ sftp sftpuser@localhost sftpuser@localhost 的密码： 已连接到本地主机。 sftp>退出
与拥有主目录的二级组的连接失败（来自 /var/log/secure）：
sshd[31640]: 已接受来自 127.0.0.1 端口 34380 ssh2 的 sftpuser 密码 sshd[31640]: pam_unix(sshd:session): 会话由 (uid=0) 为用户 sftpuser 打开 sshd[31640]: 致命: 无法将 chdir 切换到 chroot 路径“/home/sftpuser”: 权限被拒绝 [postauth] sshd[31640]: pam_unix(sshd:session): 用户 sftpuser 的会话已关闭成功连接拥有主目录的主要组（来自 /var/log/secure）：
sshd[31647]: 已接受来自 127.0.0.1 端口 34382 ssh2 的 sftpuser 密码 sshd[31647]: pam_unix(sshd:session): 会话由 (uid=0) 为用户 sftpuser 打开 sshd[31647]: 从 [127.0.0.1] [postauth] 为本地用户 sftpuser 打开会话 sshd[31647]: 来自 [127.0.0.1] [postauth] 的本地用户 sftpuser 的会话已关闭 sshd[31647]: 收到来自 127.0.0.1 的断开连接: 11: 由用户 [postauth] 断开连接 sshd[31647]: pam_unix(sshd:session): 用户 sftpuser 的会话已关闭
答案2
在阅读@Will 的回答后，我发布了一个类似的问题。我尝试了该解决方案，但无法满足我的情况。
在 Amazon Linux 上更新后，chroot 用户的权限不起作用
但它让我找到了解决方案 - 将我 chroot 的用户帐户的主 GID 更改为我用于在 chroot 目录中创建权限的组的 GID。它奏效了。