目录
问题描述
前置排查（重点：密钥和权限都是正常的）
测试Gitee SSH连通性
查看本地git远程仓库地址是否正确
真正根本原因
终极解决方案
步骤1：修改git远程仓库地址
步骤2：重新执行拉取代码
步骤3：首次连接输入yes信任指纹
成功运行效果
永久一劳永逸配置
📝 临时备选方案（切换HTTPS）
📚 总结
问题描述
今天在Linux服务器（CentOS环境）操作项目，执行git pull拉取Gitee仓库最新代码时，直接报错，连接重置，代码死活拉不下来。
报错信息如下：
ssh_exchange_identification: read: Connection reset by peer fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists从字面意思看，像是权限不对、密钥不对、仓库不存在。但实际上全都没问题。
前置排查（重点：密钥和权限都是正常的）
测试Gitee SSH连通性
先在服务器测试SSH能不能连上Gitee：
ssh -T git@gitee.com返回结果：
Hi Anonymous (DeployKey)! You've successfully authenticated, but GITEE.COM does not provide shell access. Note: Perhaps the current use is DeployKey. Note: DeployKey only supports pull/fetch operations✅说明：SSH密钥认证完全成功，密钥没问题、账号权限没问题、DeployKey部署密钥正常。
查看本地git远程仓库地址是否正确
git remote -v输出：
origin git@gitee.com:Li/bike.git (fetch)
origin git@gitee.com:Li/bike.git (push)
✅远程仓库地址一模一样，完全正确。
真正根本原因
不是密钥问题、不是权限问题、不是仓库地址问题！
真实原因就一句话：
服务器防火墙/运营商安全策略封禁了SSH默认22端口，导致git@gitee.com默认22端口连接被强制断开。
终极解决方案
Gitee官方提供了443端口备用SSH地址，专门解决22端口被封的问题。
把原来的git@gitee.com替换为ssh.gitee.com即可。
步骤1：修改git远程仓库地址
git remote set-url origin git@ssh.gitee.com:Li/bike.git步骤2：重新执行拉取代码
git pull步骤3：首次连接输入yes信任指纹
出现提示直接输入yes回车即可：
Are you sure you want to continue connecting (yes/no)? yes成功运行效果
remote: Enumerating objects: 29, done. remote: Counting objects: 100% (29/29), done. remote: Compressing objects: 100% (15/15), done. Unpacking objects: 100% (15/15), done. Merge made by the 'recursive' strategy. # 代码正常合并、更新完成代码正常拉取、自动合并，问题彻底解决。
永久一劳永逸配置
不想以后换仓库又报错，可以直接配置SSH全局映射，以后不管哪个仓库都自动走443端口。
编辑ssh配置：
vim ~/.ssh/config写入内容：
Host gitee.com HostName ssh.gitee.com Port 443 User git保存退出，以后直接用原来地址 pull、push 都不会再报错。
📝 临时备选方案（切换HTTPS）
如果SSH实在不想折腾，直接换成HTTPS地址即可：
git remote set-url origin https://gitee.com/Li/bike.git📚 总结
ssh_exchange_identification: Connection reset by peer99%是22端口被防火墙拦截；
不要瞎改密钥、不要重新生成密钥，白折腾；
直接使用Gitee备用域名ssh.gitee.com 443端口秒解决；
适合：宝塔服务器、阿里云、腾讯云、各种Linux服务器Git拉取报错场景。
