4.2 OpenSSH 2和rsync(2)

作者: 黄永兵译 出处:51CTO.com 　2008-06-19 18:38　   砖    好    评论  条 　进入论坛

阅读提示：《Linux企业集群》一书讲解如何在一个计算机网络中用有限的资源部署计算机，以及安装自由软件让计算机象一台服务器那样一起运行。其中第四章讲述用RYSNC和SSH同步服务器,本文是OpenSSH 2和rsync。

建立双向信任关系：第一步
让我们详细第检查一下这个双向信任关系是如何建立起来的，首先，客户端必须确定它是否信任服务器，然后，服务器必须确定它是否信任客户端，因此建立双向信任关系的第一步是客户端计算机确定它是否在与一个正确的服务器进行通讯。

SSH客户端应该信任SSH服务器吗？
建立一个安全的SSH传输的第一步是由客户端启动的，客户端需要知道它是否正与正确的服务器进行通讯（而不是一台被劫持了ip地址或主机名的SSH服务器），这是在SSH密钥交换过程完成的。

注意：如果你需要在一台不同的机器上重新使用一个ip地址，并重新配置你为SSH建立的安全配置，你可以通过从旧机器复制SSH密钥文件到新机器来实现。

SSH密钥交换过程
当一个SSH客户端发送一条连接请求到SSH服务器的端口22上时，就启动了SSH密钥交换过程。（如图4-2所示）

图4-2：SSH客户端连接请求

一旦服务器和客户端使用了一致的SSH协议或版本，它们将可以相互通讯（SSH版本1或SSH版本2），它们开始一个只需要最小数量数据通过网络传输的数据同步动作，这个动作的目的是为SSH会话发送足够的信息给客户端和服务器，以让它们同意共享秘密，而不在网络上发送太多信息避免黑客获取这些信息后猜测共享秘密，目前，这叫做diffie-hellman-group1-sha1密钥交换过程。

最后一件事情是在diffie-hellman-group1-sha1密钥交换过程结束时SSH服务器将最后一块数据发送回客户端，客户端需要依据它的主机密钥的公共部分算出共享秘密（如图4-3）。

图4-3：SSH服务器应答

注意：SSH服务器不会在网络上发送全部的SSH会话密钥或全部的共享秘密，这样就使得黑客在网络上嗅探猜测会话密钥几乎是不可能成功的。
至此，SSH客户端与SSH服务器之间的通讯停止，直到SSH客户端决定是否信任SSH服务器，SSH客户端通过在一个叫做known_hosts2的主机名<-->加密密钥映射的数据库中查找服务器的主机名（参考本章中的known_hosts数据库[3]），查看图4-4，如果加密密钥和主机名不在known_hosts数据库中，客户端在屏幕上显示一个提示符，询问用户这个服务器是否应该信任。

图4-4：SSH客户端在known_hosts数据库中搜索SSH服务器名字

如果SSH服务器的主机名在known_hosts数据库中，但是主机加密密钥的公共部分与数据库中的不匹配，SSH客户端不允许继续连接，并给出出错提示。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint[4] for the RSA key sent by the remote host is 6e:36:4d:03:ec:2c:6b:fe:33:c1:e3:09:fc:aa:dc:0e. Please contact your system administrator.
Add correct host key in /home/web/.ssh/known_hosts2 to get rid of this
message.
Offending key in /home/web/.ssh/known_hosts2:1
RSA host key for 10.1.1.2 has changed and you have requested strict checking.

（如果SSH服务器上的密钥发生了变化，你需要使用一个文本编辑器如vi从known_hosts数据库文件中移除损坏了的密钥）
一旦用户确定信任SSH服务器，只要存储在known_hosts数据库中的SSH服务器的主机加密密钥不发生改变，未来所有SSH连接将会自动建立。

SSH客户端最后只需要使用SSH服务器主机加密密钥的公共部分（相对于从服务器发出的共享秘密数据的最后一个数据块）执行一个数学计算确定数据来自一个正确的服务器，客户端成功执行后，它与服务器之间就建立起了一个安全的SSH传输（查看图4-5）。

图4-5：SSH客户端和SSH服务器建立一个SSH传输

现在，所有在客户端和服务器之间传输的信息可以使用会话密钥加密了（客户端和服务器的加密密钥起源于共享秘密）。

建立双向信任关系：第二步
我们叙述了一半关于在客户端和服务器之间建立双向信任关系的过程，现在，我们需要讨论另一半，在服务器上会发生什么。

服务器能够信任客户端吗？
前面我们只回答了如何在客户端和服务器之间建立双向信任关系的一半，客户端信任服务器，现在服务器需要决定它是否应该信任客户端。

基于主机的认证
历史上，基于主机的认证是使用客户端源ip地址或主机名实现的，攻击者能够很容易地攻破使用这种信任方法的服务器，他们修改他们的服务器匹配其中一个可接受的主机名，通过嗅探ip地址或劫持用于解析主机名到ip地址的DNS（域名系统）。

然而，系统管理员仍然受基于主机的认证诱惑，因为它很容易配置服务器信任所有客户端机器上的账号（甚至root账号），不幸的是，即使引入了经过改进的SSH，基于主机的认证与其他方法对比起来仍然很脆弱，它不应该被使用。

用户认证
当使用用户认证时，SSH服务器不关心是来自哪个主机的SSH连接请求，只要用户是一个可信任的用户即可。

SSH可以使用用户普通的密码和账号名用于安全的SSH传输认证，如果用户在客户端和服务器上有相同的账号和密码，SSH服务器就认为这个用户是可信任的，然而，这个方法的主要缺点是我们需要直接在SSH客户端shell脚本中输入用户的密码，用于自动连接SSH服务器，因此这种方法也不应该使用（回想我们想在主服务器和备用服务器之间自动数据同步）。

使用SSH加密密钥的用户认证
幸运的是，还有一种比前面两种都好的方法，那就是使用SSH加密密钥的用户认证，我们所要做的就是在SSH服务器上存储用户加密密钥的公共部分，当我们尝试从SSH客户端连接SSH服务器时，服务器将向我们发送一个挑战（一个使用用户加密密钥公共部分加密的随机数），只有一个知道这个加密密钥私有部分的客户端能够解码这个挑战。

SSH客户端上用户加密密钥的私有部分通常由一个密语保护，一个密语就是由用户选择的长密码（它可以包括空格），它用于在存储用户加密密钥的私有部分到磁盘前对其加密，我们将不使用密语，因为密语需要被添加到我们的自动化脚本中。

注意：你可以使用Linux入侵检测系统或LIDS来代替，使用LIDS拒绝所有用户（甚至root）对存储在磁盘上的用户加密密钥私有部分的访问。同时请查看ssh-agent的man手册对ssh-agent守护进程的描述。

这里有一个简单的双节点SSH客户端-服务器方法。

[2]在/etc/ssh目录也也可以看到DSA文件，然而，数字签名算法有一个可疑的历史，可能包含一个安全漏洞，参考Daniel J. Barrett和Richard E. Silverman编写的《SSH权威指南》。

[3]技术上，known_hosts数据库用于Open SSH v1，在Open SSH v2中被重命名为known_hosts2，我们不会用这个特征添加更多麻烦为了避免引起更多笨重的解释。

[4]你可以运行下面的命令校验SSH服务器上的“指纹”：
#ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

回书目   上一节