不输入密码ssh直接登录Linux主机的实践与总结

服务器环境：以XX云服务器，Linux版本 - CentOS为例

客户端环境：以Mac OSX Terminal为例，其他大同小异

概念说明：     

     在Terminal中用ssh命令登录服务器每次都要输入密码，虽然可以复制/粘贴密码，但登录后一段时间不操作，服务器会自动断开连接，连接时又要复制/粘贴密码，还是有些不方便。

     方法就是使用 ssh-keygen -t  [rsa|dsa]命令在本地环境生成一对公钥和私钥，然后我们把公钥复制到云服务器对应的 authorized_keys 文件中，登陆的时候云服务器就用公钥来验证我们本地的私钥。我们先介绍一下公钥，私钥和数字签名的概念：

• 公钥加密：假设我们有一个公钥public，还有一个私钥private，当我们跟好朋友Linda传送文件的时候，我们希望保护数据，所以我们可以把公钥pubic发送给Linda对要发送的文件加密。就算别人截取了这个文件，如果没有私钥private，还是无法查看文件内容。
• 私钥签名：假设我用私钥private加密一个文件（当然只有我可以用私钥加密，因为只有我保有私钥private），然后所以拥有我的公钥public的人都可以解密这个文件，而且她们能确认发送方的身份就是我，因为能够用我的公钥解密的数据，必然是用我的私钥加的密，这个过程叫做数字签名。当然具体的过程要稍微复杂一些。用私钥来加密数据，用途就是数字签名。
• 总结：
  • 公钥和私钥是成对的，它们互相解密。
  • 公钥加密，私钥解密。
  • 私钥数字签名，公钥验证。
• 举例：两个用户Alice 和Bob，Alice 想把一段明文通过双钥加密的技术发送给Bob，应该是Alice 和Bob都有一对公钥和私钥，那么加密解密的过程如下：
  1. Bob 将他的公开密钥传送给Alice , Alice 将自己的公钥给Bob。
  2. Alice 先用Bob的公开密钥加密她的消息。
  3. 然后Alice 加上自己的私钥（数字签名），然后传送给Bob。
  4. Bob 先用Alice 的公钥解密证明是Alice发的。
  5. 然后Bob 再用自己的私钥解开Alice 传来的用自己的公钥加密的文件。

具体操作：

1. 现在客户端生成公钥私钥：进入客户端的~/.ssh/目录，如果没有我们自己新建一个，在执行命令生成密钥：

   cd ~/.ssh/          
   ssh-keygen -t rsa

   网上教程中在ssh-keygen创建密钥的时候，第一个要输入密钥存放地址时，我们直接回车选择默认地址，“Enter passphrase (empty for no passphrase):”和下一行“Enter same passphrase again:”两处也都是直接回车，就是说没有创建口令短语（passphrase）。但是这是非常不安全的，如果一旦别人获取了你的私钥，那也可以直接免密直接登录你的服务器，所以还是建议要输出口令短语。更详细请参考照：
   http://www.cnblogs.com/panblack/p/Secure_ssh_trust_connection.html
2. 下面需要把公钥到目标服务器的~/.ssh/authorized_keys文件内：
   1. 此时，已经在客户端环境Mac上生成了一个公钥 id_rsa.pub和一个私钥 id_rsa，我们将公钥复制到服务器的~/.ssh/文件夹下

      scp id_rsa.pub username@server:~/.ssh/id_rsa.pub

   2. 然后登录服务器，将从客户端复制而来的公钥里的内容添加到authorized_keys（即注册）中：
      

      ssh username@server
      cd ~/.ssh
      cat id_rsa.pub >> authorized_keys

   3. 删除服务器里的公钥
      

      rm id_rsa.pub

3. 再次登录服务器，如果我们在生成秘钥时输入了口令短语，则需要输入口令短语，如果没有创建口令短语那么此时已经直接登录了。
4. 如果不能免密登录，可能还需要设置authorized_keys权限
   

   $ chmod 600 authorized_keys 

   设置.ssh目录权限
   

   $ chmod 700 -R .ssh

5. 那么现在问题又来了，我们添加了口令短语，私密安全了，但是登录麻烦了，自动化运维也不可能了。咋么办呢，我们可以用
   ssh-agent（ssh代理守护进程），让系统记住口令密语。具体操作：
   http://www.cnblogs.com/panblack/p/Secure_ssh_trust_connection.html