令人沮丧的是,SFTP用户突然停止连接到我的Amazon Linux服务器。
/ var / log / secure显示以下错误:
sshd[7291]: fatal: safely_chroot: stat("/chroot/uhleeka"): Permission denied [postauth]
在/ var /日志/安全:
==> /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
从SSHDdebugging输出:
$ /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
没有configuration更改或权限更改,但百胜更新昨天运行:
$ 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
发现在运行login程序之前,OpenSSH sshd守护程序获取了PAM环境设置。 在UseLogin = yes和configuration为读取用户环境设置的pam_env PAM模块的configuration中,本地用户可以使用此缺陷以root身份执行任意代码。
/ etc / ssh / sshd_config有:
UsePAM yes #UseLogin no #PermitUserEnvironment no
最新的更新似乎是最有可能的罪魁祸首。 是否有一个configuration问题,会导致只有chroot用户突然停止被拒绝访问最新的openssh?
编辑:这应该修复openssh-6.6.1p1-32.el7每https://bugzilla.redhat.com/show_bug.cgi?id=1398569
在OpenSSH-6.6.1p1-31更新之后出现,在SFTP连接尝试期间只有用户的主要组被检查。 使用root用户的主组拥有主目录和至less710个权限,连接尝试应该成功。
Repro步骤:
$组sftpuser sftpuser:sftpgroup sftpuser $ ls -ld / home / sftpuser / drwx - x --- 2 root sftpuser 4096 Nov 22 18:31 sftpuser / $ sftp sftpuser @ localhost sftpuser @ localhost的密码: 写入失败:pipe道破损 无法读取数据包:由对等方重置连接 $ chgrp sftpgroup sftpuser / $ ls -ld / home / sftpuser / drwx - x --- 2 root sftpgroup 4096 Nov 22 18:31 sftpuser / $ sftp sftpuser @ localhost sftpuser @ localhost的密码: 连接到本地主机。 退出
与拥有主目录的辅助组连接失败(从/ var / log / secure):
sshd [31640]:从127.0.0.1端口34380 ssh2接受sftpuser的密码 sshd [31640]:pam_unix(sshd:session):通过(uid = 0)为用户sftpuser打开的会话 sshd [31640]:fatal:无法chdir chrootpath“/ home / sftpuser”:权限被拒绝[postauth] sshd [31640]:pam_unix(sshd:session):closures用户sftpuser的会话
与拥有主目录的主组成功连接(从/ var / log / secure):
sshd [31647]:sftpuser从127.0.0.1端口34382 ssh2接受的密码 sshd [31647]:pam_unix(sshd:session):通过(uid = 0)为用户sftpuser打开的会话 sshd [31647]:为本地用户sftpuser从[127.0.0.1]开始的会话[postauth] sshd [31647]:会话已closures本地用户sftpuser从[127.0.0.1] [postauth] sshd [31647]:从127.0.0.1:11接收断开连接:由用户[postauth] sshd [31647]:pam_unix(sshd:session):closures用户sftpuser的会话
在阅读@威尔的答案后,我发布了一个类似的问题。 我尝试了这个解决scheme,但无法为我的scheme做好准备。
在Amazon Linux上进行更新后,chrooted用户的权限不工作
但是它让我想到了这个解决scheme – 将chrooted用户帐户的主要GID更改为我用来在chrooted目录中创build权限的组的GID。 有效。