荔园在线
荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: jjksam (Linux,c/c++,java), 信区: Linux
标 题: [合集]SSH的安全性重新探讨(华南木棉 Loafer)(转寄)
发信站: 荔园晨风BBS站 (Mon Nov 26 19:26:03 2001), 站内信件
jjksam (咁大个仔第一次睇到流星!:p) 于Wed Nov 21 08:48:38 2001提到:
发信人: zhch (zhch), 信区: BBSDev
标 题: SSH的安全性重新探讨(华南木棉 Loafer)(转寄)
发信站: 南京大学小百合站 (Sun Nov 18 21:40:16 2001), 站内信件
发信人: Loafer (木棉浪子), 信区: Hacker
发信站: 华南网木棉站 (Thu Apr 20 12:14:47 2000), 转信
标题: SSH的安全性重新探讨
SSH——Secure Shell,是一个很有名的安全服务工具。由于它在加密传输方面的
出色表现,已被广泛地应用起来。在一些操作系统中,已把22端口预定议
为SSH服务端口。
然而SSH是不是真的安全(Secure)呢?如何认识SSH提供的安全服务的作用及其局限
性?这里,我主要是针对自己作为一个BBS系统系统维护的角度来对SSH服务器与BBS
传统服务之间的安全关系作一些思考,提几个问题,希望能因这几块砖头,引来一
两块玉块,就算是引来几块更大的石块也没所谓,大家交流交流吧。
另外,由于时间问题,我对于SSH相关的探讨文档阅读得不多,可能有不少地方已被
讨论过了。
我提到的问题主要包括:
1. ssh 登陆的 log在哪里?
2. authorization的key如果放在$HOME下,是不是有安全问题,而放在auth/%U呢?
3. ftp问题
4. 从机理重新定义ssh的安全性
5. 其他问题
1. ssh 登陆的 log 在哪里?
ssh 的文档说,它是为了取替rhost一系列命令而作的加密。根据前人的经验,
r系列程序工具是很不安全的,不安全的地方在于主机的信任问题与用户登陆许
可问题。当主机A对主机B是信任的,而主机B上的some用户登陆主机A时,如果
主机A那边也是some,那么就不必密码认证——我对r系列的工具基本没有用过,
只能凭对书上文字的印象说说,不知道对不对。而ssh的public_key认证方式就
更惨,如果用户用pulbic_key登陆,除了root之外,全都可以不用password
这样,log就显得更重要了:
到底用户是用什么用户名上站?
用户从哪里登陆上来?
做了什么操作?
我对r系列指令不熟,可能这些log和r系列的指令有点联系..
2. authorization的key如果放在$HOME下,是不是有安全问题,而放在auth/%U下呢?
为什么说放在$HOME下有安全问题呢?对于一般的身份认证系统,身份认证是由
/etc/passwd里的login name和/etc/shadow里的password两个部分组成。也就是
说,基于登陆用户名及其对应用户密码。而对于一个系统管理员,也是习惯了这
种的认证方式的信任。
如果把key放在$HOME下,很显然就有这样的问题:无论用户名是谁,只要用在一
个用户目录,其key就一样。然而,除了身份认证使用了基于key的认证外,其他
应用,如shell,权限等,还是根据传统的login name+user id的对应关系。这就
隐藏了一个问题:如果两个用户同一个用户目录,而shell不同,以作为服务
限制,那么就变得这两个用户可能因为 public_key 的发放而同时公开给外界了。
BBS系统就是其中的典型。对于传统的BBS系统安装手册的推荐,系统管理员要建
立三个帐号,其中bbs帐号和bbsuser帐号是在同一个用户目录下,而他们的shell
不同。如果把key放在~bbs目录下,那bbsuser用户也就会暴露出来。
还有就是FTP服务,等等一些用/noshell或/bin/passwd等作为shell来让用户可以
仅仅用系统服务的功能的一部分或一方面的系统,都可能因为有小心或传统做法而
导致安全问题。
对于这个问题,我想可以采用这样的解决办法:
把key放在auth/%U下
这样就可以把身份认证与login name这种传统的方式联系起来。然而由于经验所
限,我无法作出周全的测试,所以也不能确定这样做没有其他的登陆漏洞
3. ftp问题。
如果你的主机是作BBS服务的,那就会有这样的问题:
在传统的BBS系统安装手册中,会建议你把bbs, bbsuser, bbsadm这三个用户
的用户帐号加到 ftpusers文件中,以使FTP登陆不为这三个用户服务。
记得国内某BBS站点就因为少了这一步而被改了SYSOP的密码,可见问题的严重性。
但ssh自带的ftp服务器似乎没有作ftpusers文件的检查(没有准确测试过),然而对
于缺省的sshd2_config文件来说,是开放 ftp 子服务的。
4. 如何从机理方面认识SSH,不要轻信安全与加密的神话
个人越来越讨厌广告在计算机尤其是软件方面的应用。从JAVA的吹嘘,到其他各种
各样的神话式描述,都让人作呕。并不是说它们不好,而是说:有没有这么神?
SSH安不安全,要从你的应用实际出发来看。不是加了密就安全。加密是数据传输安
全得到一定的保障。然而从服务器系统的安全方面,SSH似乎没有作更多的考虑。
记得小四写过SSH的机理,(F-Secure SSH 2.0.9 build 2与 ssh-2.0.11简介),但
主要是针对传输过程而言的。对于SSH在服务器的运作并没有作介绍。按目前的使用
经验,我认为ssh是直接与底层的服务打交道。如果从一般的telnet login shell的
概念来理解,就是ssh取替了telnetd和login过程,其直接和shell及系统命令联系。
当然,这只是从理解角度来说,从代码级对理解暂时我也说不出来,因为没时间看
代码。
5. 其他的担心。
ssh一开始就为了取替r系列的指令,而对于rexe指令它也有支持,这样的话,会不会
引来另一个担忧:
越过所有的shell,passwd等等,主要你有一个public_key或系统认证方式,
就可以指定一个工具程序来运行,比如:
/usr/bin/ls
Chair (银发) 于Wed Nov 21 16:41:44 2001提到:
所以用SSH就不用PUBLICKEY的方式嘛,用PASSWORD就可以了. 有LOG,也不存在
储存方式问题
scaner (无可奈何) 于Wed Nov 21 20:56:13 2001提到:
我觉得这些都不是ssh协议本身的问题
不过是在实现的时候的一些问题, 而且青菜萝卜
个有所爱,有些人就是喜欢这样了.
bbs现在也没有这个问题了,都是单独起bbsd
Chair (银发) 于Thu Nov 22 10:43:02 2001提到:
是啊,本来SSH就是为了解决传输过程明文被窃听和冒认的问题,协议本身用的
是非对称加密,没什么漏洞,只是认证和本地储存方面的多样性导致了有安全隐患,
安全性和可用性本来就成反比,关键是怎么找到平衡点.
BTW:你那边下雪没有?有时间EMAIL张有雪景的来看看啦.
scaner (无可奈何) 于Thu Nov 22 10:51:56 2001提到:
我现在也还在南方呀,至少算是南方,
大江南岸
tang (--------) 于Thu Nov 22 11:00:30 2001提到:
呵呵,还是古老的一次一密安全,密码表用完一次即烧掉,加密的烧,解密的也烧,
下次通讯用另一个密码表。
麻烦事就是密码表的安全该如何保证,就是实现问题了,呵呵!
scaner (无可奈何) 于Thu Nov 22 12:44:24 2001提到:
不解决根本问题的拉
Chair (银发) 于Thu Nov 22 13:10:30 2001提到:
但这样的话只要一开始通讯就给人SNIFFER了,把2边的key都窃听了去了,那就没有
安全可言了,还是用非对称比较好
bstone (毕业的季节飘荡着一丝丝无奈,迷惘) 于Thu Nov 22 13:11:31 2001提到:
rsa?
tang (--------) 于Thu Nov 22 13:19:10 2001提到:
呵呵,刚才是灌水来的。
原文狂提“ssh的public_key认证方式”不安全什么的,对ssh不是很熟悉,你解释一下吧?
我觉得如果是非对称加密,public key本来就是可以公开的,只有拿到private key的
那端才能解开用public key传送的登陆密码或其他要加密的信息,连加密者本身都解不
开这些信息。有什么不安全的?除非服务器端自己不安全,泄漏了key,这种情况用什
么加密协议都不顶用。
tang (--------) 于Thu Nov 22 13:20:44 2001提到:
开玩笑的。古代到现代的实际应用(是人手阿,呵呵)是,密码表在加解密系统
以外传送的。
scaner (无可奈何) 于Thu Nov 22 22:07:29 2001提到:
呵呵, 握手方式是这样的,
握手两端都计算出一个随机大数a, b
然后根据算法计算出c,d. 通过交换c,d
可以获得一个大家都可以知道的数e,
然后根据这个e计算出安全通道的密码.
ssh的key并不是用于握手的,只用于身份验证的.
监听者最多获得c,d, 但是不知道a, b所以
是计算不出e的
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店