概述

由于某台服务器需要对指定用户进行限制，只允许访问指定目录，这个需求在很多场景应该是比较常见的，下面介绍一种解决方案。

以下限制了sftp用户组只能sftp 连接上去至指定目录（/projects/tms_prod），ssh 连接就提示只接受sftp 连接。

方案具体流程如下：

1、创建用户及目录：

mkdir -p /projects/
groupadd sftp # 新建组
useradd -g sftp -s /bin/false tms -d /projects/tms_prod # 新建用户
passwd tms
chown root:sftp /projects/ # 修改主目录所属用户和组
chmod 755 /projects/ # 主目录授权

mkdir -p /projects/tms_prod # 为用户建立子目录
chown tms:sftp /projects/tms_prod # 修改子目录所属用户和组
chmod 755 /projects/tms_prod # 子目录授权

2、配置sshd_config

Subsystem sftp internal-sftp #指定使用sftp服务使用系统自带的internal-sftp
#Match User tms
Match Group sftp
 ChrootDirectory /projects/
 X11Forwarding no #禁止X11转发
 AllowTcpForwarding no # 禁止tcp转发
 ForceCommand internal-sftp #指定sftp命令,不能ssh连接

注意：

1.由ChrootDirectory指定的目录开始一直往上到系统根目录为止的目录拥有者都只能是root

2.由ChrootDirectory指定的目录开始一直往上到系统根目录为止都不可以具有群组写入权限

3、重启ssh服务：

service sshd restart

4、测试验证

补充：

1、Subsystem sftp
/usr/lib/openssh/sftp-server 更为 internal-sftp，这两者有什么区别呢？

简单的说默认sftp 进程由单独的二进制文件：
/usr/lib/openssh/sftp-server启动，而internal-sftp 则无需外部二进制文件额外启动一个进程，整合在sshd进程内了。

internal-sftp相较于
/usr/lib/openssh/sftp-server 优点在于：

1）性能好，无需额外进程了嘛；

2）安全性好，无需用户登录shell，且可使用ChrootDirectory 限制sftp行为活动的目录；

3）sftp-server 的存在主要是向后兼容。

2、ChrootDirectory directory

一般出现问题会在ChrootDirectory directory上，这个地方的目录不能直接配置到目标目录，需要配置到他的上一级；即给 /A/B/C的C目录做chroot,要对C能读写，所以C目录不能做ROOT目录，对B做chroot。

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~