when someone abandons you,it is him that gets loss because he lost someone who truly loves him but you just lost one who doesn’t love you.
这是一次问题定位的记录,虽然最后问题解决了,却没有定位到最根本的原因,记录它只是为了可以为后续发现同类问题的时候提供能多的思路
问题表现:服务器上配置了 ssh authorized_keys,但是登录时却还是被要求输入密码
从 sshd_config 入手
1 | $ cat /etc/ssh/sshd_config # sshd_config 中已经允许公钥认证 |
检查 authorized_keys 内容,与公钥一致没有区别,从其他服务器 scp authorized_keys 文件也做了尝试,一样没有起效
检查 authorized_keys 文件权限
1 | $ ls -l .ssh/authorized_keys |
检查 .ssh 目录权限
1 | $ ls -ld .ssh |
新学到的调试方式:直接在 server 上配置好私钥和 authorized_keys,ssh -vvv server_ip
1 | ssh -vvv server_ip |
对比了正常可登录的服务器日志,最后一句日志应该是 receive packet: type 52
通过 auth.log 获取 ssh 登录的 debug 信息
1 | # 在 sshd_config 配置 debug 信息,此处需要重启 sshd |
一顿操作猛如虎,还经历了 auth.log 不存在的问题之后,终于见到了 ssh 登录认证的 debug 信息
1 | $ more /var/log/auth.log |
很奇怪,明明是非 root 用户登录的,为什么会去找 root 的 authorized_keys,/root 下没有这个目录,自然是认证失败,这是为什么呢?(因为期间还有奇奇怪怪的尝试,所以这可能已经不是最初的问题了)
最后,虽然解决了,但是不确定是不是下面的命令生效了,并且这个指令我也没接触过,仅做记录
1
$ restorecon -FRvv ~/.ssh
这种方式两边都可以看到 debug 日志
1
2
3
4
5# server 端操作
$ sudo /usr/sbin/sshd -p 2222 -d # 在服务端启动一个临时的 sshd 服务,这个服务只能被连接一次,端口为 2222,开启 debug 模式
# client 端操作
$ ssh -vvv server_ip -p 2222
be slow to promise and quick to perform.