Linux里面 stricthostkeychecking=no作用是什么？

这是配置文件里面的语句，意思是主机公钥。

主机公钥确认 StrictHostKeyChecking StrictHostKeyChecking=no 最不安全的级别，当然也没有那么多烦人的提示了，相对安全的内网测试时建议使用。如果连接server的key在本地不存在，那么就自动添加到文件中（默认是known_hosts），并且给出一个警告。 StrictHostKeyChecking=ask 默认的级别，就是出现刚才的提示了。如果连接和key不匹配，给出提示，并拒绝登录。 StrictHostKeyChecking=yes 最安全的级别，如果连接与key不匹配，就拒绝连接，不会提示详细信息。

英语很简单又直白，这句话的意思是没有预存的总钥匙，翻译要有前言后语：if you have missed the sub key there is no host key available.

如果你掉了分钥匙，没有备用总钥匙，就没办法了！

SSH 是一种协议标准，其目的是实现 安全远程登录 以及其它 安全网络服务 。

在讨论SSH的原理和使用前，我们需要分析一个问题： 为什么需要SSH？

从1.1节SSH的定义中可以看出，SSH和telnet、ftp等协议主要的区别在于 安全性 。这就引出下一个问题： 如何实现数据的安全呢？ 首先想到的实现方案肯定是对数据进行 加密 。加密的方式主要有两种：

所谓对称加密，指加密解密使用同一套秘钥。如下图所示：

对称加密的加密强度高，很难破解。但是在实际应用过程中不得不面临一个棘手的问题： 如何安全的保存密钥呢？ 尤其是考虑到数量庞大的Client端，很难保证密钥不被泄露。一旦一个Client端的密钥被窃据，那么整个系统的安全性也就不复存在。为了解决这个问题， 非对称加密 应运而生。非对称加密有两个密钥： “公钥” 和 “私钥” 。

下面看下使用非对称加密方案的登录流程：

上述流程会有一个问题： Client端如何保证接受到的公钥就是目标Server端的？ ，如果一个攻击者中途拦截Client的登录请求，向其发送自己的公钥，Client端用攻击者的公钥进行数据加密。攻击者接收到加密信息后再用自己的私钥进行解密，不就窃取了Client的登录信息了吗？这就是所谓的 中间人攻击

从上面的描述可以看出，问题就在于 如何对Server的公钥进行认证？ 在https中可以通过CA来进行公证，可是SSH的 publish key 和 private key 都是自己生成的，没法公证。只能通过Client端自己对公钥进行确认。通常在第一次登录的时候，系统会出现下面提示信息：

上面的信息说的是：无法确认主机ssh-server.example.com（12.18.429.21）的真实性，不过知道它的公钥指纹，是否继续连接？

如果输入 yes 后，会出现下面信息：

该host已被确认，并被追加到文件 known_hosts 中，然后就需要输入密码，之后的流程就按照图1-3进行。

在上面介绍的登录流程中可以发现，每次登录都需要输入密码，很麻烦。SSH提供了另外一种可以免去输入密码过程的登录方式：公钥登录。流程如下：

经过上面的原理分析，下面三行命令的含义应该很容易理解了：

ssh-keygen是用于生产密钥的工具。

首先看下面~/.ssh中的四个文件：

四个角色的关系如下图所示：

本文以图文方式对SSH原理进行解析（主要指远程登录，没有涉及端口转发等功能）。同时分析了非对称加密的特性，以及在实践过程中如何对加密操作进行改进。

感谢@ 风笑天2013 指正，下面关于SSH的 known_hosts 机制做如下更正：

known_hosts中存储是已认证的远程主机host key，每个SSH Server都有一个 secret, unique ID, called a host key 。

当我们第一次通过SSH登录远程主机的时候，Client端会有如下提示：

此时，如果我们选择 yes ，那么该host key就会被加入到Client的known_hosts中，格式如下：

最后探讨下为什么需要known_hosts，这个文件主要是通过Client和Server的双向认证，从而避免中间人（ man-in-the-middle attack ）攻击，每次Client向Server发起连接的时候，不仅仅Server要验证Client的合法性，Client同样也需要验证Server的身份，SSH client就是通过known_hosts中的host key来验证Server的身份的。

灰常感谢大家，希望收到更多的评论指正。

---