我确实在 CentOS 上安装了 sftp 并添加了新组:
groupadd sftp
确实创建了新用户:
useradd -m sftp_user_1 -s /sbin/nologin -g sftp
确实创建了密码:
passwd sftp_user_1
确实改变了所有者:
chown root /home/sftp_user_1
确实改变了权利:
chmod 750 /home/sftp_user_1
确实改变了所有者:
chown sftp_user_1:sftp /home/sftp_user_1
确实检查了用户和组:
id sftp_user_1
[root@centos-24 home]# id sftp_user_1
uid=1000(sftp_user_1) gid=1000(sftp) groups=1000(sftp)
确实对文件 /etc/ssh/sshd_config 进行了更改
Subsystem sftp /usr/libexec/openssh/sftp-server
确实改变为
Subsystem sftp internal-sftp
是否添加到文件末尾
Match Group sftp
X11Forwarding no
AllowTcpForwarding no
ChrootDirectory /home/%u
ForceCommand internal-sftp
是否重新启动服务
systemctl restart sshd
尝试连接到 sftp 服务器并返回错误:
[root@centos-24 home]# sftp sftp_user_1@localhost
sftp_user_1@localhost's password:
packet_write_wait: Connection to ::1 port 22: Broken pipe
Couldn't read packet: Connection reset by peer
如何解决这个问题?
答案1
在这一步中
chown root /home/sftp_user_1
我必须更改并分组到 sftp
chown root:sftp /home/sftp_user_1
因为在文件 /etc/ssh/sshd_config 中存在
Match Group sftp
答案2
您的sftp
客户端报告远程端突然终止了连接。
在这种情况下,最好读取服务器端的日志:如果远程服务器确实终止了连接,服务器的日志应该这么说 - 通常他们也会说为什么服务器这样做了。
在这种具体情况下,这是我在重现问题时看到的:
Sep 23 14:53:52 centos7 sshd[1800]: Accepted password for sftp_user_1 from ::1 port 52166 ssh2
Sep 23 14:53:52 centos7 sshd[1800]: pam_unix(sshd:session): session opened for user sftp_user_1 by (uid=0)
Sep 23 14:53:52 centos7 sshd[1800]: fatal: bad ownership or modes for chroot directory "/home/sftp_user_1" [postauth]
Sep 23 14:53:52 centos7 sshd[1800]: pam_unix(sshd:session): session closed for user sftp_user_1
”chroot 目录的所有权或模式错误/home/sftp_user_1
。“因此sshd
对 的权限不满意ChrootDirectory
,在您的情况下,它等于 chroot 用户的主目录。
根据sshd_config(5)
手册页,配置参数引用的目录ChrootDirectory
必须由 root 所有,并且其他任何人都不可写入:
Chroot目录
指定身份验证后 chroot(2) 的目录路径名。在会话启动时 sshd(8) 检查路径名的所有组成部分是根拥有的目录是任何其他用户或组都不可写。 chroot 后,sshd(8) 将工作目录更改为用户的主目录。
换句话说,ChrootDirectory 不能是用户的主目录,而是至少比其高一级的目录。此要求比旧版本的sshd
.在有人发现了一种逃离 chroot 监狱的新方法之后,事情就必须如此。新的要求将使该转义方法无法使用。
请参阅我在另一个问题中的回答,了解两种可能的解决方案:https://unix.stackexchange.com/a/542507/258991
答案3
请务必检查日志中是否有与连接相关的任何错误。检查它的简单方法是使用以下命令。
grep -i username /var/log/auth.log
grep -i username /var/log/secure.log
就我而言,主目录丢失日志确实帮助我识别了问题。