标签：
但是对于在各个 IT 领域的人们，我们需要将这个事情提高一个层面。我们需要使用像 SSH 密钥这样的加密秘钥，而不只是密码。
设想一个场景：我有一个运行在云上的服务器，用作我的主 git 库。我有很多台工作电脑，所有这些电脑都需要登录到这个中央服务器去做 push 与 pull 操作。这里我设置 git 使用 SSH。当 git 使用 SSH 时，git 实际上是以 SSH 的方式登录到服务器，就好像你通过 SSH 命令打开一个服务器的命令行一样。为了把这些配置好，我在我的 .ssh 目录下创建一个配置文件，其中包含一个有服务器名字、主机名、登录用户、密钥文件路径等信息的主机项。之后我可以通过输入如下命令来测试这个配置是否正确。
ssh gitserver
很快我就可以访问到服务器的 bash shell。现在我可以配置 git 使用相同配置项以及存储的密钥来登录服务器。这很简单，只是有一个问题：对于每一个我要用它登录服务器的电脑，我都需要有一个密钥文件，那意味着需要密钥文件会放在很多地方。我会在当前这台电脑上存储这些密钥文件，我的其他电脑也都需要存储这些。就像那些有特别多的密码的用户一样，我们这些 IT 人员也被这些特别多的密钥文件淹没。怎么办呢？
在我们开始帮助你管理密钥之前，你需要有一些密钥应该怎么使用的基础知识，以及明白我们下面的提问的意义所在。同时，有个前提，也是最重要的，你应该知道你的公钥和私钥该放在哪里。然后假设你应该知道：
这里有一个例子。当你在亚马逊的网络服务上创建一个云服务器，你必须提供一个用于连接你的服务器的 SSH 密钥。每个密钥都有一个公开的部分（公钥）和私密的部分（私钥）。你要想让你的服务器安全，乍看之下你可能应该将你的私钥放到服务器上，同时你自己带着公钥。毕竟，你不想你的服务器被公开访问，对吗？但是实际上的做法正好是相反的。
你应该把自己的公钥放到 AWS 服务器，同时你持有用于登录服务器的私钥。你需要保护好私钥，并让它处于你的控制之中，而不是放在一些远程服务器上，正如上图中所示。
原因如下：如果公钥被其他人知道了，它们不能用于登录服务器，因为他们没有私钥。进一步说，如果有人成功攻入你的服务器，他们所能找到的只是公钥，他们不可以从公钥生成私钥。同时，如果你在其他的服务器上使用了相同的公钥，他们不可以使用它去登录别的电脑。
这就是为什么你要把你自己的公钥放到你的服务器上以便通过 SSH 登录这些服务器。你持有这些私钥，不要让这些私钥脱离你的控制。
但是还有一点麻烦。试想一下我 git 服务器的例子。我需要做一些抉择。有时我登录架设在别的地方的开发服务器，而在开发服务器上，我需要连接我的 git 服务器。如何使我的开发服务器连接 git 服务器？显然是通过使用私钥，但这样就会有问题。在该场景中，需要我把私钥放置到一个架设在别的地方的服务器上，这相当危险。
一个进一步的场景：如果我要使用一个密钥去登录许多的服务器，怎么办？如果一个入侵者得到这个私钥，这个人就能用这个私钥得到整个服务器网络的权限，这可能带来一些严重的破坏，这非常糟糕。
同时，这也带来了另外一个问题，我真的应该在这些其他服务器上使用相同的密钥吗？因为我刚才描述的，那会非常危险的。
最后，这听起来有些混乱，但是确实有一些简单的解决方案。让我们有条理地组织一下。
（注意，除了登录服务器，还有很多地方需要私钥密钥，但是我提出的这个场景可以向你展示当你使用密钥时你所面对的问题。）
当你创建你的密钥时，你可以选择是否包含一个密钥使用时的口令。有了这个口令，私钥文件本身就会被口令所加密。例如，如果你有一个公钥存储在服务器上，同时你使用私钥去登录服务器的时候，你会被提示输入该口令。没有口令，这个密钥是无法使用的。或者你也可以配置你的密钥不需要口令，然后只需要密钥文件就可以登录服务器了。
一般来说，不使用口令对于用户来说是更方便的，但是在很多情况下我强烈建议使用口令，原因是，如果私钥文件被偷了，偷密钥的人仍然不可以使用它，除非他或者她可以找到口令。在理论上，这个将节省你很多时间，因为你可以在攻击者发现口令之前，从服务器上删除公钥文件，从而保护你的系统。当然还有一些使用口令的其它原因，但是在很多场合这个原因对我来说更有价值。（举一个例子，我的 Android 平板上有 VNC 软件。平板上有我的密钥。如果我的平板被偷了之后，我会马上从服务器上删除公钥，使得它的私钥没有作用，无论有没有口令。）但是在一些情况下我不使用口令，是因为我正在登录的服务器上没有什么有价值的数据，这取决于情境。
你如何设计自己服务器的基础设施将会影响到你如何管理你的密钥。例如，如果你有很多用户登录，你将需要决定每个用户是否需要一个单独的密钥。（一般来说，应该如此；你不会想在用户之间共享私钥。那样当一个用户离开组织或者失去信任时，你可以删除那个用户的公钥，而不需要必须给其他人生成新的密钥。相似地，通过共享密钥，他们能以其他人的身份登录，这就更糟糕了。）但是另外一个问题是你如何配置你的服务器。举例来说，你是否使用像 Puppet 这样工具配置大量的服务器？你是否基于你自己的镜像创建大量的服务器？当你复制你的服务器，是否每一个的密钥都一样？不同的云服务器软件允许你配置如何选择；你可以让这些服务器使用相同的密钥，也可以给每一个服务器生成一个新的密钥。
如果你在操作这些复制的服务器，如果用户需要使用不同的密钥登录两个不同但是大部分都一样的系统，它可能导致混淆。但是另一方面，服务器共享相同的密钥会有安全风险。或者，第三，如果你的密钥有除了登录之外的需要（比如挂载加密的驱动），那么你会在很多地方需要相同的密钥。正如你所看到的，你是否需要在不同的服务器上使用相同的密钥不是我能为你做的决定；这其中有权衡，你需要自己去决定什么是最好的。
最终，你可能会有：
（如果你正在别的情况下使用密钥，这个同样的普适理论也能应用于如何使用密钥，需要多少密钥，它们是否共享，你如何处理公私钥等方面。）
了解你的基础设施和特有的情况，你需要组合一个密钥管理方案，它会指导你如何去分发和存储你的密钥。比如，正如我之前提到的，如果我的平板被偷了，我会从我服务器上删除公钥，我希望这在平板在用于访问服务器之前完成。同样的，我会在我的整体计划中考虑以下内容：
在你的情况中，你可能决定你不想在自己经常登录的系统上使用口令；比如，这个系统可能是一个开发者一天登录多次的测试机器。这没有问题，但是你需要调整一点你的规则。你可以添加一条规则：不可以通过移动设备登录该机器。换句话说，你需要根据自己的状况构建你的准则，不要假设某个方案放之四海而皆准。
至于软件，令人吃惊的是，现实世界中并没有很多好的、可靠的存储和管理私钥的软件解决方案。但是应该有吗？考虑下这个，如果你有一个程序存储你所有服务器的全部密钥，并且这个程序被一个快捷的密钥锁住，那么你的密钥就真的安全了吗？或者类似的，如果你的密钥被放置在你的硬盘上，用于 SSH 程序快速访问，密钥管理软件是否真正提供了任何保护吗？
但是对于整体基础设施和创建/管理公钥来说，有许多的解决方案。我已经提到了 Puppet，在 Puppet 的世界中，你可以创建模块以不同的方式管理你的服务器。这个想法是服务器是动态的，而且不需要精确地复制彼此。这里有一个聪明的方法，在不同的服务器上使用相同的密钥，但是对于每一个用户使用不同的 Puppet 模块。这个方案可能适合你，也可能不适合你。
或者，另一个选择就是完全换个不同的档位。在 Docker 的世界中，你可以采取一个不同的方式，正如关于 SSH 和 Docker 博客所描述的那样。
但是怎么样管理私钥？如果你搜索过的话，你无法找到很多可以选择的软件，原因我之前提到过；私钥存放在你的硬盘上，一个管理软件可能无法提到更多额外的安全。但是我使用这种方法来管理我的密钥：
首先，我的 .ssh/config 文件中有很多的主机项。我要登录的都有一个主机项，但是有时我对于一个单独的主机有不止一项。如果我有很多登录方式，就会出现这种情况。对于放置我的 git 库的服务器来说，我有两个不同的登录项；一个限制于 git，另一个用于一般用途的 bash 访问。这个为 git 设置的登录选项在机器上有极大的限制。还记得我之前说的我存储在远程开发机器上的 git 密钥吗？好了。虽然这些密钥可以登录到我其中一个服务器，但是使用的账号是被严格限制的。
其次，大部分的私钥都包含口令。（对于需要多次输入口令的情况，考虑使用 ssh-agent。）
再次，我有一些我想要更加小心地保护的服务器，我不会把这些主机项放在我的 host 文件中。这更加接近于社会工程方面，密钥文件还在，但是可能需要攻击者花费更长的时间去找到这个密钥文件，分析出来它们对应的机器。在这种情况下，我就需要手动打出来一条长长的 SSH 命令。（没那么可怕。）
同时你可以看出来我没有使用任何特别的软件去管理这些私钥。
我们偶尔会在 linux.com 收到一些问题，询问管理密钥的好软件的建议。但是退一步看，这个问题事实上需要重新思考，因为没有一个普适的解决方案。你问的问题应该基于你自己的情景。你是否简单地尝试找到一个位置去存储你的密钥文件？你是否寻找一个方法去管理多用户问题，其中每个人都需要将他们自己的公钥插入到 authorized_keys文件中？
通过这篇文章，我已经囊括了这方面的基础知识，希望到此你明白如何管理你的密钥，并且，只有当你问出了正确的问题，无论你寻找任何软件（甚至你需要另外的软件），它都会出现。
免费提供最新Linux技术教程书籍，为开源技术爱好者努力做得更多更好：http://www.linuxprobe.com/
标签：
原文地址：http://www.cnblogs.com/linuxprobe/p/5671743.html
