背景：前天在测试机器使用jenkins部署脚本一键构建project打包发布时，报错Execute failed，检查后发现是jenkins所在机器通过ssh远程登录应用服务器失败，导致不能把打好的工程包拷贝到服务器上，最终构建未能成功.
既然问题摆在这，那就着手开始解决它。分析下可能的原因，既然是使用ssh远程登录，那就需要机器间的互信，可以是单向的也可以是双向的。双方互信采用的方式不止一种，一般而言是采用基于非对称加密密钥的安全验证方式。互信的双方自己持有私钥，同时对方会持有私钥对应的公钥。由于这里只需要单向的互信就够了，即只要Jenkins所在机器（下称机器A）远程免密登录应用服务器（下称机器B）. 那么A需要把自己的公钥发给B。并且在首次远程登录成功之后，B的机器名或者地址会被保存在A的known_hosts文件中。
1.检查.ssh文件夹下的配置文件
首先检查B机器上 $HOME/.ssh/authorized_keys 这个文件，看A的公钥是否存在。一看发现没啥问题，然后再检查A机器上的
$HOME/.ssh/known_hosts 文件, 发现B机器已经是A机器的受信任主机了。再检查B机器上的 /etc/ssh/sshd_config ，发现各项配置也都正常。一通看下来之后，没发现哪里异常，可执行Jenkins脚本时依然还是无法免密登录！那只好在A机器上实际登录一下看看了。
2.手动进行远程登录
在机器A上，输入以下命令尝试直接远程登录
1 | ssh -v user@ip |
参数 -v 指的是verbose模式，将会打印ssh登录过程中进程的debug信息
结果依然提示需要手动输入密码
输入密码之后，再提示
这下子就真相大白了，原来是机器B上的 .ssh目录权限不符合要求，以至于A与B之间无法互信。
也就是说，B上的 .ssh目录除了目录拥有者自身可以拥有（read/write/execute）权限之外，group和others这两组身份用户是不能拥有除了read之外的权限的。于是直接在B机器上将 .ssh的目录权限修改为 744或者644
1 | chmod 744 .ssh |
- r read 权重值 4
- w write 权重值 2
- x execute 权重值 1
接着再回到机器A, 重新执行远程登录的命令。这回不用手动输入密码了，直接可以免密登录机器B了。
再重新执行之前报错的Jenkins构建脚本，发现也可以正常使用了。