如何修复GitLab流水线用scp时出现kex_exchange_identification连接重置错误

这个kex_exchange_identification: Connection reset by peer报错说明SSH客户端已经和目标服务器22端口成功建立TCP连接，但在SSH密钥交换的初始阶段就被服务端主动断开连接。结合你提供的流水线日志，ssh-keyscan能正常拉取到目标服务器的SSH指纹，说明网络层连通性没有问题，问题出在SSH服务端的访问限制、密钥校验或者版本兼容层面。

• 排查目标服务器的访问控制规则
  优先检查目标服务器的SSH登录限制：
  1. 查看/etc/ssh/sshd_config中的AllowUsers/AllowGroups/PermitRootLogin配置，确认允许root用户从GitLab Runner的出口IP登录，PermitRootLogin至少要设为without-password或者yes
  2. 检查/etc/hosts.allow和/etc/hosts.deny文件，确认GitLab Runner的IP没有被TCP Wrappers拦截
  3. 排查fail2ban、防火墙WAF之类的安全组件，确认Runner IP没有因为多次认证失败被临时封禁
• 校验SSH密钥权限和匹配关系
  1. 确认GitLab CI变量$SSH_PRIVATE_KEY对应的公钥，已经完整写入目标服务器/root/.ssh/authorized_keys文件
  2. 检查目标服务器上/root/.ssh文件夹权限为700，authorized_keys文件权限为600，权限过高会导致SSH服务端拒绝读取密钥
• 适配SSH版本兼容问题
  你的流水线客户端是OpenSSH 8.6，目标服务器是OpenSSH 7.2p2，大版本差异可能导致默认密钥交换算法不兼容，修改scp命令添加兼容参数即可：

  scp -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa -rv api.yml root@$IP:/home/services/test/
  

• 检查目标服务器运行状态
  登录目标服务器执行systemctl status sshd确认SSH服务正常运行，同时检查服务器CPU、内存、SSH最大连接数是否占满，资源不足也会导致服务端主动断开新连接。
• 开启debug日志精准定位
  如果以上排查都无效，可以在目标服务器修改/etc/ssh/sshd_config将LogLevel改为DEBUG，执行systemctl restart sshd后重新运行流水线，查看/var/log/auth.log（Debian/Ubuntu系）或/var/log/secure（CentOS/RHEL系）中的详细报错信息，即可定位具体问题。

内容的提问来源于stack exchange，提问作者Mohammad Reza Mousavi