一、缘由：
早上在用SSH公钥认证打通所有的机器，有一台机器在完成一些列操作后密钥登陆失败，其他机器一切正常。
错误如下：Public-key authentication with the server for user langxiaowwei failed. Please verify username and public/private key pair.
接着我开始懵逼，同样的操作，为什么不一样的结果呢，肯定是这台机器有问题。
环境：Ubuntu14.04
二、解决办法：
SecureCRT登陆算是一个网络交互操作吧，如果有详细日志看问题出在哪里就好了。登陆失败，在客户端来说，只有一个failed弹窗提醒，具体交互日志SecurtCRT本身
不知道去哪看（也许是我孤陋顾问）。那么就去看服务器端的日志，通过在查询认证日志auth.log后，发现如下信息：
Apr 25 11:19:21 i-5z8r7pqj sshd[32300]: User langxiaowei not allowed because account is locked Apr 25 11:19:21 i-5z8r7pqj sshd[32300]: input_userauth_request: invalid user langxiaowei [preauth]
可以看到，是因为账户被锁住（神奇，刚建的用户就被锁定。锁定原因待查。。），导致SecureCRT一直登陆失败。
那么usermod -U langxiaowei 来解锁后，使用密钥顺利登陆。
其他方法：
1、SecureCRT登陆应该是SSH操作，故我们可以在另外一个台服务器上用命令行ssh连接它，打开verbose模式（ssh -vvv），可以看到具体连接失败信息。
2、对于服务端sshd，它本身是一个服务来着，故应该可以有详细的日志以供调试查看。
将ssh服务的日志级别调整到DEBUG3（/etc/ssh/sshd_config 中LogLevel），然后重启ssh服务。之后尝试登陆同时去查看系统日志即可。
3、检查各种权限，日志后还解决不了就可能是疑难杂症了。Google后知，可能是Selinux引起的（这个具体看自己的服务器，一般我设置Selinux是初始关闭的）
三、结论：
通过这个实例，我只想说当你的服务出问题，令你抓狂解决不了的时候，看日志是正确的选择，将日志的输出到最细化，总能发现原因。
不论是脚本，程序，还是系统服务器，故我们在写脚本和程序的时候，必须要处理好日志记录和将错误及时抛出。
当然，网络世界很复杂，如果真遇到解决不了的，还得Google O(∩_∩)O~