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

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

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

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

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

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

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

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

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

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

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.

@msg7086 @asonyang9

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

@Keyes

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

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

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

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

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

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

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


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

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


以及

『是做到了保密以及签名

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

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

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

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

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

@jadec0der 学而不思则罔