sshd_config的配置:
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
Match User a
ChrootDirectory /home/logs
chown root:a /home/logs
chmod g-w /home/logs
chmod -R 755 /home/logs
原理
1
2
3
4
5
6
7
|
难道他们就真没搞明白ssh的sftp工作原理吗?当一个用户登陆系统,无论是用ssh还是sftp,ssh服务先对这个用户进行认证,
认证通过以后就会检查match里有没有这个用户,有的话match以后的语句都会对这个用户生效.
这个时候当指定ChrootDirectory.ssh会对匹配的用户进行choot的操作.以上面的配置为例,当a用户认证通过以后,
他的home目录会限定在
/
chroot这个目录,这个时候a用户如果是用的sftp协议登陆是没问题的.
但是如果a用户使用的是ssh协议,将用户的home锁定在
/
chroot,会再试图给用户加载给a用户指定的shell,
比如说是
/
bin
/
bash,而这个时候a用户的
/
是
/
chroot,所以ssh试图在
/
chroot下找
/
bin
/
bash,即:
/
chroot
/
bin
/
bash,
这个路径肯定是不存在的,所以用户a用户ssh协议登陆根本就不会登陆成功!
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
root@rainbird10:~
# tail -n 1 /etc/passwd
a:x:
1001
:
1001
:,,,:
/
home
/
a:
/
bin
/
bash
root@rainbird10:~
# ssh a@localhost
/
bin
/
bash: No such
file
or
directory
Connection to localhost closed.
root@rainbird10:~
# sftp a@localhost
Connecting to localhost...
sftp> pwd
Remote working directory:
/
sftp> cd ..
sftp> pwd
Remote working directory:
/
sftp>
|
也就是说经过以上的设置,匹配的用户只能使用sftp并锁定到指定的目录.而tcp转发和X11转发都是需要有权限登陆到系统才可以实现的功能,不知道加上有啥意义
注意
1
2
3
4
5
6
7
8
9
|
另,我的ssh版本:
root@rainbird10:~
# ssh -V
OpenSSH_5.
1p1
Debian
-
5ubuntu1
, OpenSSL
0.9
.
8g
19
Oct
2007
写到这里,权限是限制严格了,笔者也惊喜的发现,再用winscp上传完文件不能执行脚本啦!哈哈,
想想也是,都没有权限登陆还执行啥脚本呢.哎,安全和复杂总是彼增我长的.
这时候如果想让用户可以登陆的话,可以在
/
chroot下面给用户再建立简单的bash环境,
但是这样已经偏离的初衷.因为即使用户能登陆又能咋样?它执行脚本的时候也只能操作
/
chroot里的东西,
不会影响系统文件.这样虽然锁定了用户目录,但是一点意义也没有.另外linux本身就是个多用户的系统,
不发挥它多用户的优势而再搞
'子系统'
或者说
'监狱'
环境,有啥意思呢.
|
1
|
没有权限登陆还执行啥脚本
|
这才是最终的原因。
本文转自 liqius 51CTO博客,原文链接:http://blog.51cto.com/szgb17/2050090,如需转载请自行联系原作者