问题描述

在部署本地博客到服务器时,按照步骤首先创建密钥,然后把公钥粘贴到到服务器文件中vim .ssh/authorized_keys,按理来说已经配置成功了。事实上来说也应该这样,但是!早晚有一天会发现事情不是这么简单,明明已经配置好了公钥,却由于各种原因会导致我运行hexo g -d还是需要密码登录。

踩坑历程

由于我不止一个远程仓库,所以我本地保存了多对密钥,最开始我以为问题出在密钥混淆。于是我按照这篇博客的方法,配置了config文件,却发现还是不行。于是我把重心放到日志文件上,想通过日志看出一些端倪。

1
ssh -vvv 用户名@服务器ip

-vvv选项可进入ssh调试模式,v越多调试信息越详细,将日志复制到编辑器中查看,截取如下:

1
2
3
4
5
6
7
8
9
10
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /c/Users/hiltay/.ssh/id_ed25519_sk
debug3: no such identity: /c/Users/hiltay/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /c/Users/hiltay/.ssh/id_xmss
debug3: no such identity: /c/Users/hiltay/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

可以看到这一行debug2: we did not send a packet, disable method,说明数据包没有发送过去,而下一行debug3: authmethod_lookup password由于公钥验证未通过,就直接换成密码登录了。我找来了正确登录的ssh(数据已经脱敏)

1
2
3
4
5
6
7
8
9
10
debug1: Offering public key: /c/Users/hiltay/.ssh/id_rsa RSA SHA256:AbgluAsmuuOstZ08mBP0F3P4+5xMilAUFF5Sm91k9hE
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /c/Users/hiltay/.ssh/id_rsa RSA SHA256:AbgluAsmuuOstZ08mBP0F3P4+5xMilAUFF5Sm91k9hE
debug3: sign_and_send_pubkey: RSA SHA256:AbgluAsmuuOstZ08mBP0F3P4+5xMilAUFF5Sm91k9hE
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:AbgluAsmuuOstZ08mBP0F3P4+5xMilAUFF5Sm91k9hE
debug3: send packet: type 50
debug3: receive packet: type 52
Authenticated using "publickey".

可以看到正确登录的时候会直接提示Authenticated using "publickey".二者的差别就在于服务器到底收没收到公钥。

为了验证这一点,我们登录服务器,监听系统安全日志,在这里会记录SSH登录相关的日志。

1
tail -f /var/log/secure

再次本地连接服务器:

1
ssh -vvv 用户名@服务器ip

查看服务器日志,会发现有这一条(数据已脱敏):

1
Authentication refused: bad ownership or modes for directory /home/用户名

那就豁然开朗了,是文件的权限问题导致了远程无法连接。

我们查看/home/用户名路径的权限,并且查看属主和属组是否是用户

1
2
cd /home/
ll -a

然后查看.ssh目录的权限,正常的话权限应该是700,如果不是,则修改

1
chmod 700 .ssh

修改属组

1
2
chgrp [group] .ssh
# 这里group换成你用户的属组

修改属主

1
chown 用户名 /home/用户名

再次登录,免密成功。

排查方法

下面总结出一个常用的排查事项:

检查 操作示例 说明
.ssh目录的属主、属组是否为要登陆的用户与用户组 ll -a /home/[username]/ username为用户名,下同
.ssh目录的权限是否为 700 ll -a /home/[username]/
.ssh目录下authorized_keys的权限是否为644 ll -a /home/[username]/.ssh/
[username]目录的权限是否为755 ll -a /home/ 700也可以,确保其他人没有w权限

图示:

检查.ssh目录

image-20211119150246084

检查authorized_keys

image-20211119150509961

检查[username]目录权限

image-20211119150624696

感想

该踩的坑还是要踩,最大的收获就是看日志太有用了,本地的日志看不出,但是服务器上的系统安全日志把问题描述得清清楚楚。

希望对大家有帮助。