关于SSH公钥验证中错误认知的纠正

今天浏览了一些网站上关于SSH公钥验证的文章，其中关于公钥验证的具体过程，讲的不够到位，容易受其误导，需要纠正一下。

首先有一个前提是：远程服务器上已经留存了本地用户的公钥。

本地用户的公钥，一般的会留存在服务器的该用户家目录下的.ssh/authorized_keysw下文件中，至于怎么留存到服务器上，你可以通过ssh-keygen生成密钥对之后手动拷贝过去等等，这都不是重点，我们关心的只是验证的交互过程。

往往第一次登陆远程服务器时，会提示是否接受远程服务的公钥，选择是的话，会在本地主机上留存一份远程服务器的公钥，再登陆时，就不会提示了。

接下来就是重点：

1. 用户使用ssh客户端发起SSH公钥登陆请求时，会带着用户名（username）和之前生成的公钥（public key）一起，发送到服务器端。

   

2. 服务器端的SSH守护进程，就会根据发送过来的用户名，在该用户的家目录的.ssh/authorized_keys文件中查找用户提交过来的公钥，如果查找到了，就会向ssh客户端发送一个“挑战”——所谓“挑战”（英文中叫 Challenge），我们应该理解为一个名词，就是使用刚才用户的公钥去加密一个随机生成的大字符串，产生出另外一个字符串，这个新生成的字符串，就叫“挑战”。同时，“挑战”只会被另一半密钥正确解密，对于其他的密钥来说，这个字符串就是一堆看不懂的二进制（a pile of bits）。

   

3. 本地ssh客户端，在接收到服务器发来的“挑战”之后，就会使用用户自己的私钥（private key）去解密，此时，ssh客户端应该提示用户输入密钥对生成时设置的口令（当然一般情况下，用户在生成密钥对时，ssh-keygen这个玩意儿会提示我们输入一个口令，我们一般都是置空的。所以这个时候，不会有提示），输入正确后，得到解密之后的字符串

   

4. 解密过程结束后，ssh客户端接着就把解密后的字符串(key response)连同一个session id使用md5算法生成一个key repsonse，再发回给等待中的远程sshd守护进程。

   

   key respone的生成图示（红框内）：

   

5. 远程服务器端的sshd守护进接收到ssh客户端发送过来的字符串，它会先自己使用同样的md5哈希算法对之前的随机字符串和session id进行加密，完了和客户端发过来的进行比对验证。如果正确，则验证通过，允许客户端接下来的访问，如果不正确，则继续使用authorized keys列表中的下一个key进行验证直到找到一个正确的为止，若果最后还是未找到，则拒绝客户端的访问。

   

很多人关于到底是公钥加密私钥解密，还是私钥加密公钥解密这个问题表示疑惑，答案是都有，上边这个过程就很生动的讲述了到底是怎么使用的。

参考文章：http://www.unixwiz.net/techtips/ssh-agent-forwarding.html