我们中有许多人把优秀的 OpenSSH用作古老的 和 命令的替代品，OpenSSH 不仅是安全的而且是加密的。OpenSSH 更加吸引人的特性之一是它能够使用基于一对互补的数字式密钥的 RSA 和 DSA 认证协议来认证用户。RSA 和 DSA 认证承诺 不必提供密码就能够同远程系统建立连接，这是它的主要魅力之一。虽然这非常吸引人，但是 OpenSSH 的新用户们常常以一种快速却不完善的方式配置 RSA/DSA，结果虽然实现了无密码登录，却也在此过程中开了一个很大的安全漏洞。

什么是 RSA/DSA 认证？
SSH，特别是 OpenSSH（完全免费的 SSH 的实现），是一个不可思议的工具。类似于 或 ， 客户程序也可以用于登录到远程机器。所要求的只是该远程机器正在运行 ，即 服务器进程。但是，与 不同的是， 协议非常安全。加密数据流，确保数据流的完整性，甚至安全可靠的进行认证它都使用了专门的算法。

然而，虽然 的确很棒，但还是有一个 功能组件常常被忽略、被危险的误用或者简直就是被误解。这个组件就是 OpenSSH 的 RSA/DSA 密钥认证系统，它可以代替 OpenSSH 缺省使用的标准安全密码认证系统。

OpenSSH 的 RSA 和 DSA 认证协议的基础是一对专门生成的密钥，分别叫做 专用密钥和 公用密钥。使用这些基于密钥的认证系统的优势在于：在许多情况下，有可能不必手工输入密码就能建立起安全的连接。

尽管基于密钥的认证协议相当安全，但是当用户并不完全了解这些简化操作对安全性的影响，为了方便而使用某些简化操作时，就会出现问题。本文中，我们将详细讨论如何正确使用 RSA 和 DSA 认证协议，使我们不会冒任何不必要的安全性风险。在我的下一篇文章里，我将向您展示如何使用 隐藏已经解密的专用密钥，还将介绍 ，它是 的前端，可以在不牺牲安全性的前提下提供许多便利。如果您一直想要掌握 OpenSSH 更高级的认证功能的话，那么就请您继续往下读吧。

RSA/DSA 密钥的工作原理
下面从整体上粗略的介绍了 RSA/DSA 密钥的工作原理。让我们从一种假想的情形开始，假定我们想用 RSA 认证允许一台本地的 Linux 工作站（称作 localbox）打开 remotebox上的一个远程 shell， remotebox 是我们的 ISP 的一台机器。此刻，当我们试图用 客户程序连接到 remotebox时，我们会得到如下提示：

此处我们看到的是 处理认证的 缺省方式的一个示例。换句话说，它要求我们输入 remotebox上的 drobbins 这个帐户的密码。如果我们输入我们在 remotebox 上的密码， 就会用安全密码认证协议，把我们的密码传送给 remotebox 进行验证。但是，和 的情况不同，这里我们的密码是加密的，因此它不会被偷看到我们的数据连接的人截取。一旦 remotebox 把我们提供的密码同它的密码数据库相对照进行认证，成功的话，我们就会被允许登录，还会有一个 remotebox 的 shell 提示欢迎我们。虽然 缺省的认证方法相当安全，RSA 和 DSA 认证却为我们开创了一些新的潜在的机会。

但是，与 安全密码认证不同的是，RSA 认证需要一些初始配置。我们只需要执行这些初始配置步骤一次。之后， localbox 和 remotebox 之间的 RSA 认证就毫不费力了。要设置 RSA 认证，我们首先得生成一对密钥，一把专用密钥和一把公用密钥。这两把密钥有一些非常有趣的性质。公用密钥用于对消息进行加密，只有拥有专用密钥的人才能对该消息进行解密。公用密钥只能用于 加密，而专用密钥只能用于对由匹配的公用密钥编码的消息进行 解密。RSA（和 DSA）认证协议利用密钥对的这些特殊性质进行安全认证，并且不需要在网上传输任何保密的信息。

要应用 RSA 或者 DSA 认证，我们要执行一步一次性的配置步骤。我们把 公用密钥拷贝到 remotebox。公用密钥之所以被称作是“公用的”有一个原因。因为它只能用于对那些给我们的消息进行 加密，所以我们不需要太担心它会落入其它人手中。一旦我们的公用密钥已经被拷贝到 remotebox并且为了 remotebox 的 能够定位它而把它放在一个专门的文件（~/.ssh/authorized_keys）里，我们就为使用 RSA 认证登录到 remotebox上做好了准备。

要用 RSA 登录的时候，我们只要在 localbox 的控制台键入 ，就象我们常做的一样。可这一次， 告诉 remotebox 的 它想使用 RSA 认证协议。接下来发生的事情非常有趣。 Remotebox 的 会生成一个随机数，并用我们先前拷贝过去的公用密钥对这个随机数进行加密。然后， 把加密了的随机数发回给正在 localbox 上运行的 。接下来，轮到我们的 用 专用密钥对这个随机数进行解密后，再把它发回给 remotebox，实际上等于在说：“瞧，我 确实有匹配的专用密钥；我能成功的对您的消息进行解密！”最后， 得出结论，既然我们持有匹配的专用密钥，就应当允许我们登录。因此，我们有匹配的专用密钥这一事实授权我们访问 remotebox。

两项注意事项
关于 RSA 和 DSA 认证有两项重要的注意事项。第一项是我们的确只需要生成一对密钥。然后我们可以把我们的公用密钥拷贝到想要访问的那些远程机器上，它们都会根据我们的那把专用密钥进行恰当的认证。换句话说，我们并不需要为想要访问的 每个系统都准备一对密钥。只要一对就足够了。

另一项注意事项是 专用密钥不应落入其它人手中。正是专用密钥授权我们访问远程系统，任何拥有我们的专用密钥的人都会被授予和我们完全相同的特权。如同我们不想让陌生人有我们的住处的钥匙一样，我们应该保护我们的专用密钥以防未授权的使用。在比特和字节的世界里，这意味着没有人是本来就应该能读取或是拷贝我们的专用密钥的。

的开发者们当然知道专用密钥的重要性，而且他们已经在 和 里加入了一些防范措施，以防止我们的专用密钥被滥用。首先， 被设置成了如果我们的密钥的文件权限允许除我们之外的任何人读取密钥，就打印出一条大大的警告消息。其次，在我们用 创建公用／专用密钥对的时候， 会要求我们输入一个密码短语。如果我们输入了密码短语， 就会用该密码短语加密我们的专用密钥，这样，即使专用密钥被盗，对于那些碰巧不知道密码短语的人而言，这把专用密钥是毫无用处的。具备了这一知识后，让我们看一下如何设置 以应用 RSA 和 DSA 认证协议。

ssh-keygen 细探
设置 RSA 认证的第一步从生成一对公用／专用密钥对开始。RSA 认证是 密钥认证的最初形式，因此 RSA 应该可以用于 OpenSSH 的所有版本，尽管这样，我还是推荐您安装可用的最近版本，在我写这篇文章的时候是 openssh-2.9_p2。生成一对 RSA 密钥的方法如下：

当 要求输入存放密钥的缺省位置时，我们敲回车键接受缺省的 /home/drobbins/.ssh/identity。 将把专用密钥保存在此路径中， 公用密钥就存在紧临它的一个叫做 identity.pub 的文件里。

还要请您注意一下 还提示过我们输入密码短语。当时我们输入了一个好的密码短语（七位或者更多位难以预测的字符）。然后 用这个密码短语加密了我们的专用密钥（~/.ssh/identity），以使我们的专用密钥对于那些不知道这个密码短语的人将变得毫无用处。

追求快速的折衷方案
当我们指定密码短语时，虽然这使得 保护我们的专用密钥以防误用，但是也带来了一点小小的不便。现在，每当我们试图用 连接到 drobbins@remotebox 帐户时， 都会提示我们输入该密码短语以便它能对我们的专用密钥进行解密，并使用我们的专用密钥进行 RSA 认证。此外，我们输入的不是 remotebox上 drobbins 帐户的密码，而是在本地机器上对专用密钥进行解密所需要的密码短语。一旦我们的专用密钥被解密，我们的 客户程序就会处理其余的事情。虽然使用我们的远程密码和使用 RSA 密码短语的机制完全不同，但实际上还是会提示我们输入一个“保密的短语”给 。

这里就是人们经常会被误导而导致追求快速的折衷方案的地方。有很多时候，仅仅是为了不必输入密码，人们就会创建不加密的专用密钥。那样的话，他们只要输入 命令，立刻就会通过 RSA（或是 DSA）认证并登录。

然而，尽管这样很方便，但是在还没有完全理解这种方法对安全性的影响时，您不应该使用。如果有人在某一时刻闯入了 localbox，一把不加密的专用密钥使得他们也自动有权访问 remotebox以及其它所有用这把公用密钥配置过的系统。

我知道您在想些什么。无密码认证，虽然有点冒险，可看起来的确很诱人。我完全同意。但是， 还有更好的办法！请相信我，我将向您展示如何既可以享受到无密码认证的好处，又不必牺牲专用密钥的安全性。在我的下一篇文章里，我还将向您展示如何熟练的使用 （正是它最先使得 安全无密码认证成为可能）。现在，让我们通过设置 RSA 和 DSA 认证为使用 做好准备。下面是逐步的指导。

RSA 密钥对的生成
要设置 RSA 认证，我们需要执行生成公用／专用密钥对的一次性步骤。我们的输入如下：

出现提示时，请接受缺省的密钥位置（典型的情况下是 ~/.ssh/identity 和存储公用密钥的 ~/.ssh/identity.pub），并提供给 一个安全的密码短语。一旦 完成，您将会得到一把公用密钥和一把用密码短语加密的专用密钥。

RSA 公用密钥的安装
接下来，我们需要把正在运行 的远程系统设置成使用我们的 公用 RSA 密钥进行认证。典型情况下，我们通过象下面这样把公用密钥拷贝到远程系统完成这一步：

由于 RSA 认证还没有完全设置好，所以会提示我们输入 remotebox上的密码。请您照做。然后，登录到 remotebox 并把公用密钥附加到文件 ~/.ssh/authorized_keys 上，如下所示：

现在，配置过 RSA 认证以后，当我们试图使用 连接到 remotebox 时，应该会提示我们输入 RSA 密码短语（而不是我们的 密码）。

好哇，RSA 认证的配置完成了！如果刚才没有提示您输入密码短语，您可以试验一下以下几种情况。第一，尝试通过输入 登录。它会让 只应用 ssh 协议版本 1，如果出于某种原因远程系统缺省设置的是 DSA 认证的话，可能会要求这么做。如果不奏效的话，请确认您的 /etc/ssh/ssh_config 里没有写着这么一行 。如果有的话，请您在前面加上一个“#”把这行注释掉。另外，还可以试着同 remotebox 的系统管理员联络，核实一下在他们那一端已经启用了 RSA 认证，并且 /etc/ssh/sshd_config 里的设置是正确的。

DSA 密钥的生成
协议的版本 1 使用的是 RSA 密钥，而 DSA 密钥却用于协议级 2，这是 协议的最新版本。目前所有的 OpenSSH 版本都应该既能使用 RSA 密钥又能使用 DSA 密钥。DSA 密钥以如下类似于 RSA 密钥的方式使用 OpenSSH 的 生成：

又会提示我们输入密码短语。输入一个安全的密码短语。还会提示我们输入保存 DSA 密钥的位置。正常情况下，缺省的 ~/.ssh/id_dsa 和 ~/.ssh/id_dsa.pub 就可以了。在我们一次性生成 DSA 密钥完成后，就该把我们的 DSA 公用密钥安装到远程系统上去了。

DSA 公用密钥的安装
DSA 公用密钥的安装又是几乎和 RSA 安装完全一样。对于 DSA，我们将要把 ~/.ssh/id_dsa.pub 文件拷贝到 remotebox，然后把它附加到 remotebox 上的 ~/.ssh/authorized_keys2 文件。请注意这个文件的名字和 RSA 的 authorized_keys 文件名不同。一旦配置完毕，输入我们的 DSA 专用密钥的密码短语就应该能登录到 remotebox，而不需要我们输入在 remotebox 上真正的密码。