Hadoop学习入门（二）——部署关键问题1：OpenSSH 密钥管理(1)
在Hadoop的配置过程中涉及到ssh免密钥登录的问题，所以我们对于ssh的密钥管理需要有一定的清晰的认识。网络上提供的很多方法对于大家来说就是彻头彻尾的误导，今天我就研究一下免密钥的ssh登录的方法。
OpenSSH（free ssh实现）具有一个非常诱人的特性就是它能够给予一对互补的数字式密钥RSA和DSA认证协议来认证用户。RSA和DSA认证承诺不比提供密钥就能够同远程系统建立连接，这也是它最大的魅力之一，虽然说很多的用户很轻松的实现了免密钥登录，但是与此同时，开了一个很大的安全漏洞。
什么是RSA/DSA认证？
ssh客户程序可以用于登录到远程的机器，所以只需要远程机器正在运行sshd，即是ssh服务进程。不同于我们在计算机网络课上学习到的telnet，ssh协议是十分安全的，加密数据流保证数据完整性，甚至安全可靠的进行认证它都是用了专门的算法。
虽然说ssh很棒，很安全，但是ssh的一个功能组件常常被忽略，被危险的误用或者简直就是被误解。这个组件就是OpenSSH的RSA/DSA密钥认证系统，它可以代替OpenSSh缺省使用的标准安全密码认证系统。
OpenSSH 的 RSA 和 DSA 认证协议的基础是一对专门生成的密钥，分别叫做专用密钥和公用密钥。使用这些基于密钥的认证系统的优势在于很多时候不用手动输入密码就能够进行安全的连接。
RSA/DSA密钥的工作原理
假定我们想用 RSA 认证允许一台本地的 Linux 工作站（称作 localbox）打开 remotebox 上的一个远程 shell，remotebox 是我们的 ISP 的一台机器。此刻，当我们试图用ssh 客户程序连接到 remotebox 时，我们会得到如下提示：
% ssh drobbins@remotebox drobbins@remotebox's password: |
它会要求我们输入remotebox上drobbins用户的密钥。我们输入密码之后，ssh就会用安全密码协议把我们的密会传送到remotebox上进行验证。这里的密码是经过加密的，所以不会被正在头盔我们数据连接的人所窃取。验证成功之后我们就会被允许登录还会有一个欢迎的提示。大家可以通过ssh localhost测试一下。虽然ssh缺省的认证方式很安全，但是RSA/DSA认证却有一些潜在的漏洞。
与ssh安全密码认证不同，RSA认证需要一些初始配置。我们只需要执行这些配置步骤一次，之后，localbox和remotebox之间的RSA认证就毫不费力了。要设置RSA认证，我们首先要生成一对密钥，一把专用密钥和一把公用密钥。这两把密钥中，公用密钥用于对消息进行加密，只有拥有专用密钥的人才能对信息进行解密。公用密钥只能用来加密，而专用密钥只能用于对由匹配的公用密钥编码成的消息进行解密。RSA和DSA认证协议利用密钥对的这些特殊性质进行安全认证，并且不需要在网上传输任何保密后的数据。
要应用RSA或者DSA认证，我们需要执行以下步骤：
1.把公用密钥拷贝到remotebox。
2.公用密钥为remotebox的sshd能够定位它存放在一个专门的文件里，这个位置就是网上大部分文章说的~/.ssh/authorized_keys
3.用户进行RSA登录，在localbox的控制台键入ssh drobbins@remotebox
4.ssh告诉remotebox的sshd，localbox请求RSA认证。
5.remotebox的sshd生成一个随机的数，用公共密钥进行加密。
6.sshd把加密的随机数发送给locolhost上的ssh
7.ssh利用专用密钥进行解密，解密出随机数并发送给remotebox
8.remotebox知道locolbox拥有能够解密的专用密钥，sshd允许localbox登录。
9.localbox被授权访问remotebox，连接建立。
问题与思考
显然对于所有的需要与namenode进行连接的节点来说只需要公用一份公用密钥就可以了，这样namenode就能访问所有的datanode。
对于专用密钥，一旦专用密钥落入一些不怀好意的人手中，任何拥有专用密钥的人都会被授予和我们完全相同的权限。所以，应该保护专用密钥预防未授权的使用。
但是这个文件的复制和拷贝是不可避免的。怎么办？ssh和用于产生这对密钥的ssh-keygen一定有一些办法能够处理这种问题。
在ssh和ssh-keygen中已经加入了一些防护措施，防止我们的专用密钥被滥用。开发者们做了以下几点：
1.ssh被设置成了如果我们的密钥的文件权限允许除我们之外的任何人读取密钥，就打印出一条警告消息。
2.其次，在我们用ssh-keygen创建公用/专用密钥对的时候，ssh-keygen就会要求我们输入一个密码，如果我们输入了passphrase，那么ssh-keygen就会用该密码短语加密我们的专用密钥，这样即使专用密钥被盗了，对于不知道passphrase的人来说专用密钥毫无作用。
ssh-keygen使用
% ssh-keygen Generating public/private rsa1 key pair. Enter file in which to save the key (/home/drobbins/.ssh/identity): (hit enter) Enter passphrase (empty for no passphrase): (enter a passphrase) Enter same passphrase again: (enter it again) Your identification has been saved in /home/drobbins/.ssh/identity. Your public key has been saved in /home/drobbins/.ssh/identity.pub. The key fingerprint is: a4:e7:f2:39:a7:eb:fd:f8:39:f1:f1:7b:fe:48:a1:09 drobbins@localbox |
本机实测
ssh-keygen要求我们输入存放密钥的缺省位置，我们敲回车，默认的地址是/home/blueline/.ssh/id_rsa。专用密钥存放在这个路径的文件中
公用密钥保存在/home/blueline/.ssh/id_rsa.pub中。
ssh-keygen提示我们输入的passphrase就是用于加密我们的专用密钥，以使得不知道passphrase的人对于他们来说，专用密钥没有任何用处。
again问题
虽然说我们指定了passphrase保证了我们的专用密钥防止了被误用滥用，但是出现了麻烦，我们每次试图进行ssh链接的时候，链接到blueline@hadoop都必须输入passphrase，并使用我们的专用密钥进行RSA认证。此外，我们输入的不是remotebox上drobbins的用户密码而是我们设定的passphrase。
# ssh drobbins@remotebox Enter passphrase for key '/home/drobbins/.ssh/identity': (enter passphrase) Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org Welcome to remotebox! % |
这时候，不少人就会产生这样的想法，诶，我搞一个不加密的专用密钥吧，那样的话，只需要简单的ssh命令，就能直接通过RSA或者DSA认证，进行登录
# ssh drobbins@remotebox Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org Welcome to remotebox! % |
虽然说，这样很方便，也满足了需求，但是，问题随之诞生了，安全性受到了影响，如果有人闯入了localbox，一把不加密的专用密钥让他们有权访问remotebox以及其他所有拥有公用密钥配置的系统。
显然，这也不是我们所期望的，因为风险太大了，所以是否有能够较为安全的办法呢？（其实是有的，那就是之后会说到的ssh-agent）
以RSA协议为例子（DSA）类似 辅以ssh-agent完成无密码输入
1.RSA密钥对的生成：
% ssh-keygen -t rsa |
这里-t后面的参数缺省时是rsa，表示选择的协议类型。
在本机的操作示意图如下
我设置的passphrase就是保密短语是：richardhu
如果不输入任何路径的时候，缺省的专用密钥存储在~/.ssh/id_rsa
2.复制密钥到指定的机器（这里是hadoop@hadoop00）
% scp ~/.ssh/id_rsa.pub hadoop@hadoop00:/home/hadoop/.ssh/authorized_keys |
在本机的操作示意图如下
登录到指定的机器上进行验证
在hadoop@hadoop00上的对应目录已经发现了我们拷贝过来的authorized_keys
3.启动ssh-agent
% ssh-agent |
在本机的操作示意图如下
4.添加id_rsa到ssh-agent
% ssh-add id_rsa |
在本机的操作示意图如下
在添加id_rsa时需要确认passphrase，输入richardhu
5.成功
我们在ssh-agent的帮助下第一次实现了免密钥登录!!!!!!!!
那么什么ssh-agent的工作机理是什么，他是否有什么安全上的问题，是否有更完善的更优秀的取代方案，且看下次的博文。
