洗澡时，我终于跑出来喊出了我的 Eureka

[ChristopherWu]

来自我的公众号『 YongHao 写东西的 Cache 』 打个小广告，还是希望写的东西有人看🙊

洗澡时，我终于跑出来喊出了我的 Eureka

今天与一位帅气的同事一起解决了一下 ssh 的相关问题，在我装逼的提及不需要显式指定 identity key 的时候，顺道提及 known_hosts 也是一样的时候，说到了known_hosts的现象：

• 第一次 ssh 到一台服务器，需要用输入 yes 来确认此服务器；

• 当一个已经连接过的域名换服务器时，会禁止连接，警告有可能有中间人，需要手动删除known_host 里的此记录；

但是原理被含糊不清的略过去了———至少没有刻意提到，因为我是不大懂的。

在今晚洗澡时，回想了一下今天的事情，想到了这件事情，不禁尝试想清楚 kown_host 是啥东西，为什么需要它。

前几天看到知乎上，有一篇文章介绍了拉马努金自己尝试推导一切未知但已成结论的数学公式，作者学习此方法自己尝试推导出机器学习的论文。

不知道是不是潜意识的影响（我在那时肯定没想到这篇文章），我在结合以上已知 known_host 的两点现象，以及以前零散的 ssh 原理知识，尝试推导 ssh 为什么运作的。

RSA 的原理无需累述，就用我以前总结过的为介绍吧：

RSA 是非对称加密算法, 对称算法就是双方用同一个密钥加密。RSA 是基于对两个质数相乘容易，而将其合数 分解很难的这个特点进行的加密算法 生成公钥与私钥, 公钥加密而私钥解密, 或者相反都可以。 一般公钥公开到网上, 想发送信息给你的人用公钥加密, 而只有你拥有私钥可以解密, 这样确保了信息的保密。 或者你用私钥加密, 其他所有人都可以用公钥解密你的信息, 这样可以确保信息是由你所发出。 网上发邮件或者个人网站上所用到的签名, 就是使用此技术。

而 SSH 就是利用了这个原理，你可以从此方面尝试去推导出你如何做一个 ssh。

而我推导出的过程是这样的：

目的就是 server 要识别 client 就是 authorize_keys 里记录的 client

1. 在 server 上的authorize_keys里添加 client 的公钥了(这步大家都知道)

2. client 发起 ssh 连接到 server，发送公钥给 server

3. server 用 client 发送的公钥对比 authorize_keys里的记录是否一致，认证 client 是否有权限

4. 此时 server 发送一个字符串（如"generated by server"）发送给 client，目的就是 client 用私钥加密后，发回去后，server 可以解密，与记录的字符串对比一致

5. 此时可以确认 client 就是authorize_keys 里记录的 client 了

以上一切完成。

为什么需要known_host呢？ 上述过程有一个问题就是，无法抵御中间人攻击。

假如在你以后链接 server 时，被中间人攻击了，中间人模仿 server 的行为与你进行 ssh 校验，你就会连上去，并且难以发现。

因此显然易见的一个方法就是，在第一次建立连接成功后，在一个文件里记录 IP，公钥这样的键值对，以后连接时对比一下与第一次连接的公钥是否一致即可。 而这个文件就被 ssh 命名为 known_hosts ，因此不一致时，拒绝了你的 ssh 连接，并且提示 中间人攻击。

那么保证第一次连接是对的话，就只有人工去对比了。 服务器自己公开公钥信息了，客户端自己去对比。

---

对比结果

事后对比，以上的做法是对的，只是没那么严谨。

有以下几个细节是不同的：

1. 客户端应该是需要发送公钥到服务器的，目前没有看到有说明这个的地方，需要再查
2. 发送的固定字符串，不是用明文，而是用客户端的公钥加密了
3. 服务器发给客户端去做私钥加密时，生成的不是固定的字符串，而是随机字符串（这个是细节没有打磨，因为发送固定字符串，明显客户端私钥加密过的东西是固定的，就无法保密了）
4. 最后对比这个随机字符串时，还用了SessionKey来做 md5，还没细查

---

感想

以上的文章，技术细节不怎么重要，重要的是背后的一些大家都知道道理：

对一切保持好奇心，尽量探寻其中的原理，这才对得住计算机科学。赫歇尔对好奇七色光实验为何会有额外的温度变化才发现不可见光（红外线，紫外线呢），法拉第不懈尝试各种材料才发现玻璃能帮助磁场让光改变路径，证实磁场与光有关联。 计算机也是基于黑盒上完整的生态圈，如 HTTP，TCP，CPU，PL 等，同样可以对他们保持好奇心，与用拉马努金的方法来推导构建此黑盒，与自己的对比，想必大有裨益。

花絮

Why Eurekai ? Eureka – （希腊语：εὕρηκα；拉丁化：Eureka ；词义：“我发现了!”）

阿基米德在洗澡时发现浮力原理，高兴得来不及穿上裤子，跑到街上大喊：“Eureka！”

古希腊学者阿基米德 (Archimedes)，有一天，他在洗澡的时候发现，当他坐进浴盆里时有许多水溢出来，这使得他想到：溢出来的水的体积正好应该等于他身体的体积，这意味着，不规则物体的体积可以精确的被计算，这为他解决了一个棘手的问题。阿基米德想到这里，不禁高兴的从浴盆跳了出来，光着身体在城里边跑边喊叫着 “尤里卡！尤里卡！”，试图与城里的民众分享他的喜悦。

So.. Eureka! Eureka!

在自己设计想清楚了 SSH 之后，我在寒冬不禁高兴的从浴室跳了出来，光着身体在客厅边跑边喊叫着 “ Molly，Molly ”， 跟女票论述了我此番的感想。

因为她对 ssh 原理心中一直有根刺，也很感兴趣，让我把 ssh 以及 RSA 的原理都给她说了一遍，草稿如下：

---

3，5，7，11，13，17。。。

191 (13,17)

公钥 《=》私钥

• 公钥加密的东西，可以用私钥来解 =》 别人用我的公钥加密的东西，我有私钥，只有我才能解密，知道这是什么
• 私钥加密的东西，同样可以用公钥来解 => 我加密的东西，别人可以用我公开的私钥来解密 =》 这些东西就是你加密的（这就是你的东西）

公钥暴露，别人无法暴力破解对比出私钥

=》私钥永远不能暴露，不能发送出去，只能放自己机器。

公钥 私钥

公钥放 GitHub 服务器

molly ssh 到 GitHub =》 molly 发起 ssh 链接 -》 发公钥给 GitHub -》 GitHub 就可以跟你放 GitHub 服务器的公钥做对比，校验你有没有权限 -》“随机生成的字符串” 发给 molly -》 molly 用私钥来加密随机生成的字符串 ，发给 GitHub -》 GitHub 用 molly 的公钥来解开这个内容，对比是否刚刚发给 molly 的随机字符串 =》一切都通了。

中间人 =》 你要想像中间随便有一个人可以监听你的网络

molly -- chalres -- github

1. SSL
2. ~/.ssh/known_hosts

[KasuganoSoras]

比较好奇你女票怎么看你

[saluton]

图呢？

[jadec0der]

思而不学则殆

[ChristopherWu]

@jadec0der 学而不思则罔

[jasonyang9]

道理我都懂，然而。。。

```
ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no YOUR_IP
```

[Ruohua3kou]

学习了，谢谢

[ChristopherWu]

@asonyang9 之前没有了解过这些参数，刚刚我查了一下，有什么问题吗~

[artandlol]

好无聊的，加密只是诞生于人的互不信任。

[likuku]

如此这般... 我觉得摘选官方手册 /摘选动物书《 XX 权威指南》，改写成如今“白话文” 就能出书卖钱了喂。

[EscYezi]

@artandlol 如果每个人都值得信任，加密当然没必要了😂

[ChristopherWu]

@likuku 你说的方法，与我这篇文章所说的东西不一样。。

[Keyes]

私钥加密公钥能解这条就完全颠覆了非对称理论

[ChristopherWu]

@Keyes 这是我一直以来的理解。刚刚我去查了一遍，"私钥加密公钥能解" 这个说法应该是没问题的。请看： https://www.zhihu.com/question/25912483 里面相关讨论内容。

除数字签名外，一般的用法都是公钥加密，私钥解密，反之很少见，所以可能你不太清楚。

[winglight2016]

@EscYezi 你这么一说，我想起看过一部电影，说得就是未来的人全部无法说出假话，有一个人忽然觉醒了谎言技能，然后大家都把他当作了 God

[ChristopherWu]

@Keyes 你看我发给你的那个知乎问题里面，第一个回答里可以找到我两年前的评论：😂


『那么我用自己的私钥加密，再用对方的公钥加密；
对方接收后用自己的私钥解密后，再用我的公钥解密；

是不是就做到了 保密以及签名了呢？"』


以及

『是做到了保密以及签名

在局域网不可信的情况下， 这个方法可以对抗被动的搭线攻击，但是不能防御中间人和重放攻击。』

[Keyes]

@ChristopherWu 然而实际上呢？

[zhaode]

你说的这些只是工程问题而已呀

[bestie]

@ChristopherWu [私钥加密公钥能解] 这句话没错，但是就 ssh 来说应该不是这个原理
1. 发出登陆请求后是 server 使用 client 提供的 public key 来加密某个随机字符串然后发送给 client
2. client 使用 private key 解密后做摘要算法发回 server
3. server 使用同样的摘要算法 通过对比 client 发回的值来验证是否有权限

而不是你所说的 client 使用私钥加密发送到 server 再使用 public key 解密

[msg7086]

@Keyes 私钥加密公钥能解，这种非对称加密如何颠覆非对称理论？

[ChristopherWu]

@bestie 感谢你的回复，这里我说的应该是有问题的，我发这文章之前看到有人写过是用到了 SessionKey 做摘要算法，所以在文章里有写到：
『最后对比这个随机字符串时，还用了 SessionKey 来做 md5，还没细查』

我有空查查 RFC 再跟你对对哈~

[hxndg]

@Keyes
那要不呢？你真的理解啥是非对称吗？

[jasonyang9]

话说 真打算花几小时来搞明白 SSH 的密钥认证机制还不如去看下源码

[jasonyang9]

@ChristopherWu #7 懒得看它一堆输出警告什么的，干脆屏蔽了

[ChristopherWu]

@jasonyang9 这操作可以。不过我还是不偷懒了-_-

[chinvo]

并没有发送公钥这一步，发送的是用你的私钥签名的登录请求，然后服务器用你的公钥验签。

而 known hosts 里面的私钥即使你用密码登录，也是会先获取服务器的公钥，因为服务器给返回的所有数据都会用服务器的私钥签名。

[jadec0der]

@ChristopherWu 所以你知道「因此显然易见的一个方法就是，在第一次建立连接成功后，在一个文件里记录 IP，公钥这样的键值对，以后连接时对比一下与第一次连接的公钥是否一致即可。」这句话里的公钥，和你文章之前出现的公钥都不是同一个公钥吗？为什么不说清楚呢

[ChristopherWu]

@jadec0der 那天事情发生后，凌晨三点多仓促而成的文章。。有很多错漏的~

[Keyes]

@hxndg
@msg7086
@ChristopherWu

几位说的没错，我对非对称具体的数学原理并不了解，我的意思是，如果在真实的应用中，私钥可以推导出公钥，那公钥是不是也能推导出私钥了？

[msg7086]

@jasonyang9 @ChristopherWu
我是
alias sss='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

专门用来连接一次性有效的服务器，比如 Rescue CD 上临时启动的 SSH 等等，可以防止污染正常的 hosts 文件，也方便。

[msg7086]

@Keyes
密码学中的私钥推导不出公钥，公钥也推导不出私钥。
真实的应用中，私钥文件中保存了公钥和私钥的参数，所以可以「生成」出公钥（注意，不是用私钥算出公钥）。

[ChristopherWu]

@Keyes

文章是这样写的『一般公钥公开到网上, 想发送信息给你的人用公钥加密, 而只有你拥有私钥可以解密, 这样确保了信息的保密。 或者你用私钥加密, 其他所有人都可以用公钥解密你的信息, 这样可以确保信息是由你所发出』

并不是互相推导， 而是 公钥加密的， 可以用私钥来解密出内容。 反之亦然。

[ChristopherWu]

@msg7086 @asonyang9

我刚刚想了想，是有用的。我现在过几天就有一台新服务器要连，而我又不会真的去对比公钥，所以他让我输入 yes 那个步骤是没有用的。。

[msg7086]

@Keyes 另外，密码学上的私钥和公钥在地位上是可以互换的，因为他们在数学公式上本来就是对称的。
真实的应用中，为了简化操作，作为「公钥」的那一边，有一个参数是固定值（ 65537 ），而作为「私钥」的那一边，同样的参数是一个随机值，这才有了私钥和公钥的区别。
如果两边的参数都是随机值，那么两边的任意一边都可以做私钥，另一边可以做公钥。

[vjnjc]

我是来看你题目里面的那个英文啥意思的。。。

[ChristopherWu]

StrictHostKeyChecking 设置为 accept-new 对我有用。

整理一下提到的 ssh 参数：
GlobalKnownHostsFile
Specifies one or more files to use for the global host key database, separated by whitespace. The default is /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2.

UserKnownHostsFile
Specifies one or more files to use for the user host key database, separated by whitespace. The default is ~/.ssh/known_hosts, ~/.ssh/known_hosts2.

StrictHostKeyChecking
If this flag is set to yes, ssh(1) will never automatically add host keys to the ~/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed. This provides maximum protection against man-in-the-middle (MITM) attacks, though it can be annoying when the /etc/ssh/ssh_known_hosts file is poorly maintained or when connections to new hosts are frequently made. This option forces the user to manually add all new hosts.
If this flag is set to “ accept-new ” then ssh will automatically add new host keys to the user known hosts files, but will not permit connections to hosts with changed host keys. If this flag is set to “ no ” or “ off ”, ssh will automatically add new host keys to the user known hosts files and allow connections to hosts with changed hostkeys to proceed, subject to some restrictions. If this flag is set to ask (the default), new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases.

[Keyes]

@msg7086 您好再请教一下，关于数字签名中的问题

我理解的，日常环境中使用非对称密钥对做消息签名是：
1、A 将 message 做 hash，得到 hash(msg)
2、用 A 的 private key 对做一次加密得到 rsa(hash(msg))
3、将 message/hash 算法 /加密过的 hash 发送给 B
4、B 用 A 公钥解密 hash，再对消息做一次 hash，看是否等于 rsa(hash(msg))
这样就完成了一次点到点的签名认证（先不提 MITM 和中立机构的事儿）

我不能确定的是 4，B 真的可以用 A 的公钥把 hash 原文解出来吗？

[miyuki]

对不起，我以为你在玩 FF14

[msg7086]

@Keyes 我们先排除掉像是 SSH 之类协议的问题，光说公钥私钥本身。
假如 priv 是私钥，pub 是公钥。
1. A 将 message 加密 rsa_encode(priv, msg) 得到密文 MM。
2. A 将 MM 发送给 B。
3. B 将 MM 解密 rsa_decode(pub, msg) 得到明文 message。

message 是什么都可以，用作验证签名的时候是 hash，但是也可以直接用来加密。

反过来如果 B 要把信息加密发给 A。
1. B 将 message 加密 rsa_encode(pub, msg) 得到密文 MM。
2. B 将 MM 发送给 A。
3. A 将 MM 解密 rsa_decode(priv, msg) 得到明文 message。

[jadec0der]

@ChristopherWu 我觉得吧，你如果没有意识到 SSH 连接中有两套公私钥，其中一套专门用来认证 known host 的话，那你这文章其实什么都没搞明白。这就是我为什么说「思而不学则殆」。

当然也可能你搞明白了只是没写出来，冒犯请见谅。

[a268479513]

@Keyes 不是，hash 跟加密是两回事，hash 的出现不是为了加密，而是为了保证消息在传输过程中没有变化，所以你说公钥能解密 hash，这个当然是不行的啊，一般如果用了 hash 加密的话，消息原文一定也会通过密钥（或者公钥）加密发送出去，接收者在接收到消息后除了要解密密文，还得解密明文，然后用明文 hash 一下看看得到的结果是不是跟密文相同，如果不同，说明消息被改过了，如果相同，则说明消息没错。hash 是这个作用，并不是加密的作用的

[ChristopherWu]

@jadec0der 我确实不知道 『 你如果没有意识到 SSH 连接中有两套公私钥，其中一套专门用来认证 known host 的话』, 但不至于『这文章其实什么都没搞明白』吧。。。

我之后会再去看相关的东西的，不影响先做『自己的设计猜想』，再去对比的，所以不至于「思而不学则殆」啦。

我觉得我最大的问题是 学而不思。。写代码时，遇到 bug 时，遇到不清楚的技术细节时，通常都是看别人的说法，看书，而没有经过自己的日常思考，导致不牢固。

[Neoth]

计算机科学，所有内容都是人类自己编造出来的，这种事儿，还需要你 “尤里卡” ？？？
人家自然科学家发现了前无古人发现 的新自然规则，那才叫 “尤里卡”。

你这个不去看 RFC，自己蹲浴缸玩阿加莎克里斯蒂的，叫文青意淫

[cxh116]

你要的 ~/.ssh/known_hosts 里的公钥一般对应在 /etc/ssh 目录下的公钥.

为了保险,你可以手动把服务器的公钥添加到客户端的 ~/.ssh/known_hosts 文件里再去建立连接,就像把客户端的公钥手动添加到服务器 ~/.ssh/authorized_keys 目录一样..
或在连接时检查提示的公钥和服务器的公钥的指纹是否一致也行 (ssh-keygen -lf /etc/ssh/ssh_host_xxx_key.pub 查看指纹).

[ChristopherWu]

@Neoth 我觉得你有点误解了这篇文章了。。

[Neoth]

@ChristopherWu 木有误解，还是 “再造轮子” 的激情在鼓舞着你

[hxndg]

@Keyes
私钥并不能推导出公钥，这两者是密码学的概念即用其中一个加密，只能用另外一个解密。
很多情况下把公钥当成私钥，把私钥当成公钥，并非不可以，只不过是需要将原本的私钥公开，而原本的公钥不公开罢了。

[Keyes]

@hxndg 谢谢，感谢指点

[Keyes]

@msg7086 总之核心思想就是就是用一个来加密就只能用另一个解密，反之一样

[msg7086]

#41 @ChristopherWu 这块确实我看帖子的时候也看漏了。

SSH 密钥连接有两个密钥对。一个是 SSH 密钥对，也就是服务器下 /etc/ssh/ 下面 ssh_host 开头的密钥，这个是用来证明服务器是服务器的，公钥会写在客户端的 known_hosts 里。另一个是登录密钥对，也就是客户端下 ~/.ssh/ 下面 id 开头的密钥，这个是用来证明你是你的，公钥会写在服务器的 authorized_keys 里。你写帖子的时候应该是把这两个东西搞混了。

再另外，为了达到完美向前安全性，现代的 SSH 都采用 DHE 起手做加密了，公钥私钥仅仅用来认证，而不会用于通讯加密了。DHE 方面你有兴趣也可以去看看，很有意思的。

[msg7086]

@Keyes 是的，他们的地位是对等的。一般软件里用的私钥文件已经包含私钥和公钥了。而公钥文件只有公钥。

[ChristopherWu]

@msg7086 对的，我完全不知道有服务器在 `/etc/ssh/ssh_host_rsa_key`有自己的公钥。
我猜是一台服务器上有多用户，都可以生成自己的公私钥，这个公钥不能作为服务器的公钥的。

所以服务器自身需要唯一的公钥，就是你说的这个，用来证明服务器是服务器的。

[ChristopherWu]

@msg7086 果然是我提前就特别关注的大佬

[jadec0der]

@ChristopherWu 从 SSH 的角度看，登录服务器分为两部分，第一步是利用服务器的公私钥建立安全的连接，第二步是用户向服务器证明自己的身份（通过用户的公私钥或者密码）。这就类似你用 https 登录 v2ex，你想的那个密钥是你的用户名密码，实际上 known host 是 HTTPS 证书，完全驴头不对马嘴，我觉得说你什么都没搞明白不过分。

从信息安全的角度看，公钥完全是公开信息，比如 github 会要求你上传公钥，比如你可以在 keybase.io 公布公钥，比如 R.Stallman 会在网站上公布自己的公钥供大家验证他的身份。你想的因为服务器知道你的公钥，所以它就是真的服务器，可以说是莫名其妙。

言尽于此，

[ChristopherWu]

@jadec0der 我现在知道你的意思了。

但是你可以看看 @msg7086 在 #49 的回复，我觉得他理解了我说了什么，哪里说错了。。

『莫名其妙』不至于。。。

[msg7086]

@ChristopherWu 嗷过奖了。
网络上大家说话可能比较随便，有时候语气会重一些，就不要太在意啦，背后实际上是没有恶意的。

[20015jjw]

只能说 eureka 家的汉堡太好吃

[petelin]

@jadec0der 大佬就是大佬，一小段话就看懂了。不知道楼主要干啥，就不能看看书？

[p1gd0g]

@msg7086 弱弱的问一句，在公钥密码体制下哪一个密码学算法中私钥不能“推导”出公钥？

另外，“向前安全性”->“前向安全性”。

把俺一个密码学硕士看懵逼啦。。。

[FrankD]

@ChristopherWu “确保信息是由你所发出”，目的是防抵赖。加签验签来干这事儿的，不是加密解密。加密那是为了信息隐匿。

[MrLonely]

RSA 只支持别人用公钥加密你用私钥解密确保只打算给你看的内容不会被别人看去了，Elliptic curve 才是你用私钥加密别人用公钥解密让别人能确定这条信息是你发的不是别人假冒你发的。

[forcecharlie]

我有个不成熟的建议，ssh -Tvvv 可以看流程。

[msg7086]

@p1gd0g 拿 RSA 举例，公钥是 n&e，私钥是 n&d，可以通过 n 和 d 推导出 e 的值吗？
反正我是想不出在没有公钥那一半数据的情况下私钥如何去「推导」出公钥的那一半。

[p1gd0g]

@msg7086 俺明白自己为啥懵逼啦，看啦两年的论文全是基于离散对数问题，而 RSA 是基于整数分解问题。
在 RSA 中 e * d = 1 mod \lambda(n)，在已知 \lambda(n) 的情况下是可以对公私钥相互转换的，但是 \lambda(n) 不可以公开。在这种情况下，密钥生成和分发会引发一些安全性问题，这可能也是基于整数分解问题的研究越来越少的原因吧。

感谢指正。

[msg7086]

@p1gd0g 像 RSA 这样的算法，只要保存有足够的原始参数信息，就相当于把私钥和公钥一起保存下来了。
如果只拥有「私钥」部分，是无法推出「公钥」部分的，所以我才说实际应用中相当于把公钥和私钥一起存了。
其他的算法我也不太清楚，毕竟我不是学密码学出身的，只能说略知皮毛了。