![无法使用公钥/私钥身份验证通过 SSH 无需密码即可访问默认端口 22](https://linux22.com/image/914806/%E6%97%A0%E6%B3%95%E4%BD%BF%E7%94%A8%E5%85%AC%E9%92%A5%2F%E7%A7%81%E9%92%A5%E8%BA%AB%E4%BB%BD%E9%AA%8C%E8%AF%81%E9%80%9A%E8%BF%87%20SSH%20%E6%97%A0%E9%9C%80%E5%AF%86%E7%A0%81%E5%8D%B3%E5%8F%AF%E8%AE%BF%E9%97%AE%E9%BB%98%E8%AE%A4%E7%AB%AF%E5%8F%A3%2022.png)
我已经正确设置了目标服务器的私钥/公钥身份验证。它在我升级之前就运行了。该服务器是 GitLab CE 服务器,运行来自Ubuntu 16.04
存储库的综合发行版。升级过程完成后,当我无法对目标服务器执行推送/拉取时,发现了这个问题。结果发现主要问题可能不是由于 GitLab。我使用的 GitLab 版本是GitLab CE 12.1.3
${HOME_USER}/.ssh/
我已经检查了普通用户以及/var/opt/gitlab/.ssh/
gitlab 默认主目录的目录权限。它被配置为700
。- 该
authorized_keys
文件还配置为600
- 两个
.ssh/
目录均由其用户(例如用户 git)完全拥有 - 我也尝试过重新生成私钥/公钥,使用多种类型
ed25519
以及rsa
/etc/ssh/sshd_config
我确实检查了/etc/ssh/ssh_config
,它只是像通常那样配置,它应该可以正常工作- 我确实发现这是一种奇怪的行为,如果我使用默认端口(22),日志似乎没有触发公钥认证,但它在其他端口上运行良好
- 未应用
ufw
、firewall
、fail2ban
等selinux
设置
以下是我尝试通过端口 22 连接时收到的日志
MacBook-Pro-2:.ssh urhen$ ssh -vT [email protected]
OpenSSH_7.8p1, LibreSSL 2.6.2
debug1: Reading configuration data /Users/urhen/.ssh/config
debug1: /Users/urhen/.ssh/config line 2: Applying options for gitlab-ce.example.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: /etc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to gitlab-ce.example.com port 22.
debug1: Connection established.
debug1: identity file /Users/urhen/.ssh/gitlab/id_rsa type 0
debug1: identity file /Users/urhen/.ssh/gitlab/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to gitlab-ce.example.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:mDG0M8BFZ4vMyAD1OKjgC1/RHORl1WtalFqfDMthWLA
debug1: Host 'gitlab-ce.example.com' is known and matches the ECDSA host key.
debug1: Found key in /Users/urhen/.ssh/known_hosts:47
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password
debug1: Next authentication method: password
[email protected]'s password:
自定义端口有以下日志,使其能够通过公钥进行身份验证
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
而默认端口 (22) 总是需要密码验证,没有其他选择。我已附上这两个端口的完整日志成功.txt(自定义端口)和不成功.txt(端口 22)这里
我欢迎“人为错误”的可能性,并感谢你们的关注和建议。之前我发过一篇关于错误论坛,我相信这是正确的论坛。
编辑: 我找到了解决方案,实际上是根本原因,原来是防火墙/网关强制执行特定策略,该策略仅接受网络前端端口 22 的密码身份验证。它已应用于公司网络,其影响在这里更容易重现。实际上,只要取消策略并使用现有配置,它就会立即起作用。