我已经正确设置了目标服务器的私钥/公钥身份验证。它在我升级之前就运行了。该服务器是 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 的密码身份验证。它已应用于公司网络，其影响在这里更容易重现。实际上，只要取消策略并使用现有配置，它就会立即起作用。