装完 Git敲下git clone的那一瞬间报错就来了——Permission denied (publickey)、Host key verification failed、unable to access一路换协议换端口还是失败。这类问题在 Windows 上尤其高频因为 Git 本身只是一套版本控制工具真正负责把数据搬过网络的环节是 OpenSSH 或 HTTPS而 Windows 上的 SSH 环境往往是Git 自带一份、系统可选功能一份两者版本、配置文件、密钥目录各走各的稍微错位一点克隆远程仓库就直接卡住。这篇内容围绕 Git 基础操作、Windows 下安装 OpenSSH、以及用 HTTPS 与 SSH 两种协议克隆远程仓库时的报错排查展开适合刚接触 Git 的新手也适合那些能提交能拉取但一出认证问题就抓瞎的进阶使用者。1. 先把 Git、OpenSSH 和两种传输协议的关系理清楚很多人排查克隆报错的效率低根本原因不是命令不会敲而是脑子里没有一张清晰的分层图哪一层负责什么、报错信息属于哪一层。先把这张图搭起来后面所有的排错都会变成按层定位而不是碰运气。1.1 Git 本身不负责网络传输它只是个调度者Git 的核心职责是内容寻址的对象数据库你提交的每个文件都会被算出一个哈希存成 blob、tree、commit 三种对象。至于这些对象怎么从本地跑到远端、怎么从远端拿回本地Git 自己并不实现而是把活儿外包给传输层。这个外包的设计有个直观的好处换传输方式不用换 Git。你从 HTTPS 切到 SSH命令还是git clone、git push变的只是底层调用的程序。git clone https://...时Git 调起的是内置的 libcurl走 HTTP/HTTPS 协议栈git clone git...时Git 调起的是一个外部进程ssh.exe把数据通过 SSH 管道传出去。理解这一点很多报错就自解释了一半看到Permission denied (publickey)你可以立刻判断问题出在 SSH 那一层跟 Git 的仓库逻辑、分支、对象都无关反过来看到fatal: not a git repository那才是 Git 层面的事。分层判断能省掉大量无谓的尝试。我见过不少新手在认证失败后开始折腾git config --global里各种参数甚至重装 Git 三遍实际上一个字符都没改对地方。原因就在于没分清这是传输层的错还是这是 Git 层的错。1.2 Windows 上到底有几个 ssh.exe这是最容易出问题的点类 Unix 系统里ssh只有一份路径清楚行为一致。Windows 不是。在常见的开发机上你可能同时存在两三份 ssh 可执行文件来源典型路径说明Windows 可选功能 OpenSSH ClientC:\Windows\System32\OpenSSH\ssh.exe系统组件版本随系统更新cmd 与 PowerShell 默认能找到Git for Windows 自带C:\Program Files\Git\usr\bin\ssh.exe随 Git 安装Git Bash 里优先使用这一份包管理器安装例如用户目录下的~\scoop\shims\ssh.exePATH 位置决定谁先被命中问题来了这三份 ssh 在使用~/.ssh/config、known_hosts、密钥文件时行为大体一致但默认路径和版本细节会有差异。更关键的是~的展开规则在不同 shell 下可能指向不同目录——Git Bash 里~是/c/Users/你的用户名而某些终端里可能是别的。实际的坑是这样的你在 Git Bash 里ssh-keygen生成了密钥密钥落在C:\Users\你的用户名\.ssh\id_ed25519。然后你在 PowerShell 里敲git cloneGit 调起的可能是系统那份 ssh.exe。如果两者对 HOME 的解析不一致ssh 就会去别的地方找密钥找不到然后报Permission denied (publickey)。你明明看到密钥就在那儿它就是不认。判断当前到底在用哪一份一行命令就够git config --show-origin --get core.sshCommand where.exe ssh第一条看 Git 是否被显式指定了 ssh 路径第二条列出 PATH 里所有 ssh 的位置顺序即优先级。在 PowerShell 里用Get-Command ssh -All能看到更完整的信息。1.3 一次 clone 在底层到底跑了哪几步把克隆拆成可观测的步骤排查时才有抓手。以 SSH 协议为例git clone gitexample-host:team/demo.git大致经历解析仓库地址把gitexample-host:team/demo.git拆成用户名git、主机example-host、路径team/demo.git。建立 TCP 连接连接到主机端口SSH 默认是 22。这一步失败会看到Connection timed out或Connection refused。主机密钥校验对比服务端返回的主机公钥和本地known_hosts里的记录。首次连接会提示确认指纹不匹配会报Host key verification failed。用户身份认证用私钥签名挑战值服务端用你上传的公钥验证。失败就是Permission denied (publickey)。启动远端 git 进程服务端执行git-upload-pack两边的 Git 开始协商要传哪些对象。传输与落地打包、压缩、传输本地解包成对象文件最后检出工作区。HTTPS 协议的前几步类似只是把 2 到 4 换成了 TLS 握手 HTTP 认证用户名密码或凭据管理器里的令牌端口通常是 443。这张流程图的价值在于任何一条报错你都能立刻对上号。超时归第 2 步指纹归第 3 步认证归第 4 步early EOF、index-pack failed归第 6 步。归了类排查范围立刻缩小到一两个方向。2. Windows 安装 OpenSSH 的三条路径与各自的门道安装本身不难难的是装完之后Git 用的到底是不是它。这部分我把三条路径都走一遍并说明各自的适用场景和容易忽略的细节。2.1 图形界面设置里的可选功能最直白的路径是系统设置里的可选功能。打开设置 → 应用 → 可选功能 → 添加功能搜索 OpenSSH会看到两个条目OpenSSH 客户端和OpenSSH 服务器。绝大多数人只需要装客户端。客户端提供ssh.exe、ssh-keygen.exe、ssh-agent.exe、scp.exe、sftp.exe这一套工具作用是从这台机器连出去。服务器端提供的是sshd.exe作用是被别人连进来——除非你要把本机当作跳板或做本地测试否则没必要装而且装完会多一个常驻服务占端口、吃内存还可能和企业终端管理策略冲突。安装完成后C:\Windows\System32\OpenSSH\下会出现可执行文件。这个路径本身就在系统 PATH 里所以新开的终端窗口里ssh -V直接可用。注意必须新开窗口已经打开的 PowerShell 或 cmd 不会自动刷新环境变量这是装完还是提示找不到命令最常见的原因没有之一。提示如果添加功能列表里搜不到 OpenSSH通常是系统版本较旧或功能被策略隐藏。这种情况下别硬折腾图形界面直接走下面的命令行方式更省事。2.2 命令行安装一条命令搞定还能批量复现以管理员身份打开 PowerShell先查状态Get-WindowsCapability -Online | Where-Object Name -like OpenSSH*输出里State字段如果是NotPresent就是没装Installed就是已装。安装客户端Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0那串~~~~0.0.1.0看着奇怪它是 Windows 功能包的版本后缀不是笔误照抄即可。安装过程需要联网下载组件耗时几十秒到几分钟不等。装完验证ssh -V ssh-keygen -V 21注意ssh -V是大写 V小写 v 是详细日志模式两个完全不同的东西。有次我在文档里写错大小写导致一位同事以为装失败排查了半天从此我写这类命令都格外注意。命令行的好处是可脚本化。如果你要给一批机器配置开发环境写进初始化脚本里比一台台点界面靠谱得多。2.3 Git for Windows 自带的那份其实已经够用了这里说个可能让新手意外的结论装 Git for Windows 的时候已经顺带装了一份完整的 OpenSSH位置在C:\Program Files\Git\usr\bin\。在 Git Bash 里敲ssh -V命中的就是这一份。所以对很多人来说Windows 上装 OpenSSH这一步其实是可以跳过的——只要你的操作始终在 Git Bash 里进行并且 Git 的core.sshCommand没有指向别处。那为什么还要装系统那份几个实际理由终端一致性习惯用 PowerShell 或 cmd 的人希望ssh、scp在任何终端都能直接用。版本新鲜度系统组件的 OpenSSH 通常会跟随系统更新某些老版本 Git 自带的 OpenSSH 对新算法比如某些 sk- 硬件密钥类型支持滞后。避免路径争议某些脚本或 IDE 内置终端不继承 Git 的路径设置用系统那份更省心。反过来也有理由只保留一份。两份共存时最容易出现我在 A 终端生成的密钥B 终端读不到的情况。我的习惯是装系统 OpenSSH 客户端然后用core.sshCommand显式指定全局统一的 ssh 路径让 Git 不管在哪个终端被调起都用同一个程序。git config --global core.sshCommand C:/Windows/System32/OpenSSH/ssh.exe路径里用正斜杠或者用双反斜杠转义单反斜杠会被当作转义字符吃掉配置文件里就会出现一个不存在的路径。2.4 PATH 与 HOME两个不起眼但决定成败的环境变量ssh.exe找密钥的逻辑是先看命令行有没有-i指定没有就去~/.ssh/找默认文件名id_rsa、id_ed25519、id_ecdsa等再结合~/.ssh/config里的IdentityFile指令。这里的~取决于HOME或USERPROFILE环境变量。在 Git Bash 中~通常被解析成C:\Users\用户名在某些精简过的终端或 IDE 内置终端里HOME可能没设置ssh 的行为就会变得难以预测。排查时先把这几个值打出来看一眼echo $HOME echo $USERPROFILE ls -la ~/.ssh如果~/.ssh列不出文件而你又确认密钥存在那基本就是路径解析的问题而不是密钥本身的问题。解决办法是在~/.ssh/config里用绝对路径写死IdentityFile绕开~展开的不确定性。这一招我用过很多次屡试不爽。3. 生成密钥、配置 config让远端认得出你密钥这一环出问题的频率比安装环节高得多。原因很朴素安装失败是没有工具报错信息明确密钥失败是工具在但对方不认你报错信息含糊全靠推断。3.1 ssh-keygen 的参数怎么选passphrase 要不要设生成密钥的基础命令ssh-keygen -t ed25519 -C work-laptop-2024 -f ~/.ssh/id_ed25519_work逐项解释-t ed25519算法选 Ed25519。它比 RSA 短得多公钥一行私钥也短签名速度快现代服务端普遍支持。如果目标环境明确只支持 RSA用-t rsa -b 4096密钥长度别低于 3072。-C后面跟的是注释会附在公钥末尾。它不参与认证纯粹是给人看的标记。多台机器、多个用途时写上机器名和日期将来在服务端列表里一眼认出哪把是哪把能省下这把密钥还有没有用的纠结。-f指定输出路径。不指定就落在默认位置。passphrase 强烈建议设。私钥文件本质是一个明文文件谁拿到谁就能以你的身份操作。设了 passphrase私钥在磁盘上就是加密的被拷走也用不了。代价是每次用都要输一次——这个问题用 ssh-agent 解决见 3.4。但要注意passphrase 不等于服务端密码。新手常见的错误是把 passphrase 输错几次后以为密钥坏了其实只是记错了口令。真忘了也没有找回机制只能重新生成一对把新的公钥传上去。生成后会得到两个文件id_ed25519_work 私钥权限必须是仅本人可读 id_ed25519_work.pub 公钥可以随便传在 Windows 上~/.ssh目录的权限由 NTFS ACL 控制。Git Bash 里ls -l显示的-rw-------是模拟出来的实际生效的是 Windows 权限。如果 ssh 抱怨私钥权限过宽UNPROTECTED PRIVATE KEY FILE在 Git Bash 里可以这样收紧chmod 600 ~/.ssh/id_ed25519_work在纯 PowerShell 环境里需要用icacls去掉继承并只授权当前用户稍麻烦一些。所以我的建议是密钥的生成和权限修整都在 Git Bash 里做一次到位。3.2 公钥传上去了还是 Permission denied四种常见原因这是最让人抓狂的场景明明把.pub的内容整段复制粘贴到了远端账户的公钥设置里保存成功回头git clone还是Permission denied (publickey)。按概率从高到低排查第一复制错了文件。传上去的必须是.pub结尾的公钥不是没有后缀的私钥。这听起来很低级但确实是最高频的失误。私钥内容通常以-----BEGIN OPENSSH PRIVATE KEY-----开头公钥是ssh-ed25519 AAAA... 注释一行。看一眼就知道。第二复制时被换行或空格污染。公钥必须是一整行。从终端复制时如果不小心折行或者编辑器自动格式化插入了换行服务端解析就会失败。稳妥的做法是用命令直接输出再复制cat ~/.ssh/id_ed25519_work.pub在 PowerShell 里用Get-Content -Raw ~/.ssh/id_ed25519_work.pub加-Raw很关键不加会输出成数组粘出来带一堆换行。第三ssh 压根没用这把密钥。默认情况下 ssh 会尝试~/.ssh/下的默认文件名你自定义成id_ed25519_work它当然不会主动去试。这时必须显式指定ssh -i ~/.ssh/id_ed25519_work -T gitexample-host或者写进 config推荐见 3.3一劳永逸。用-v能看到详细过程其中Offering public key:那几行直接告诉你 ssh 到底递了哪把钥匙给服务端一眼就能看出是不是选错文件。第四服务端根本没读你的公钥。如果你是把公钥加到了某个部署密钥Deploy Key位置那它通常只对单个仓库有效且可能默认只读如果是组织账户还要确认密钥有没有被加到实际使用的那个账户下而不是另一个同名账户。这类问题在个人账户上少见在团队协作环境里不少。提示用ssh -vT git主机名跑一次日志里搜Offering、Server accepts key、Authenticated、Authentications that can continue这几个关键词定位速度比反复试命令快得多。3.3 一份 config 管所有主机和多套密钥~/.ssh/config是 SSH 世界里性价比最高的一份配置文件。它把你每次都要敲的那堆参数固化下来还顺便解决了多账户密钥冲突的问题。一个实用模板Host work-repo HostName repo.example-host.com User git Port 22 IdentityFile C:/Users/你的用户名/.ssh/id_ed25519_work IdentitiesOnly yes Host personal-repo HostName repo2.example-host.com User git IdentityFile C:/Users/你的用户名/.ssh/id_ed25519_personal IdentitiesOnly yes几个点值得展开IdentityFile用绝对路径。前面说过~展开有不确定性配置文件里写死最稳。Windows 路径在 ssh config 里用正斜杠或双反斜杠。IdentitiesOnly yes是很多人忽略却极有用的一行。不加它ssh 会把 agent 里、默认目录里的所有密钥挨个试一遍。一旦某个服务端对失败次数有限制多数平台限制在几次试到一半就可能被临时禁用你还一脸茫然。加上它ssh 只递你指定的那一把。Host后面的名字是自定义别名。配置好之后克隆命令变成git clone work-repo:team/demo.git比原来的gitrepo.example-host.com:team/demo.git短还自带用哪把密钥的语义。多账号并存时这个别名就是切换身份的总开关。3.4 ssh-agent把 passphrase 输入次数降到一次设了 passphrase 之后每次都输确实烦。ssh-agent 是一个在后台常驻的进程你解锁一次密钥它就替你保管到会话结束。Windows 系统自带的 OpenSSH 客户端包含 agent 服务需要先启动并设为自动Get-Service ssh-agent | Set-Service -StartupType Automatic Start-Service ssh-agent ssh-add ~/.ssh/id_ed25519_workssh-add的一次性口令输入就是那个 passphrase之后同一会话内不再询问。列表用ssh-add -l查看。如果用的是 Git for Windows 自带的 ssh路径下也有对应的ssh-agent但和系统服务是两套。混用时会出现我明明 add 过了怎么还问我要口令的情况——因为你在 A 层 add 了B 层去问。判断方法简单ssh-add -l如果提示Could not open a connection to your authentication agent说明当前 shell 里 agent 环境没生效。Git Bash 通常通过.bashrc里的eval $(ssh-agent)那一行启动新开的窗口要重新执行。在 Windows 上我倾向于统一用系统 OpenSSH 的 agent 服务配好自启动一次配置长期有效也避免了每个终端窗口单独起 agent 的麻烦。4. 克隆报错的分层排查链路前面铺垫了那么多环境知识目的就是这一节任何报错出现时能快速归到某一层然后沿着那一层往下走。我把常见的报错按层做了个分类表遇到不认识的先查表定位。报错关键词所属层典型原因Permission denied (publickey)SSH 认证密钥未被提供、未被接受、账户不匹配Host key verification failedSSH 主机校验known_hosts中密钥变更或缺失Connection timed out/Connection refused网络传输端口不通、主机名解析失败、访问策略限制Could not resolve hostDNS主机名拼错或 DNS 配置异常fatal: unable to access ... 443HTTPS 传输证书、凭据、访问策略SSL certificate problemHTTPS 证书自签证书、根证书缺失、系统时间错误RPC failed/early EOF/index-pack failed数据落地仓库过大、连接中断、内存不足fatal: not a git repositoryGit 层路径不对、.git缺失4.1 Permission denied (publickey) 的完整排查链这条报错是所有 Git 使用者都会撞上的。不要急着重装、不要急着换协议按下面的顺序走一遍绝大多数情况十分钟内能定位。第一步确认网络和端口是通的。用ssh -vT git主机名跑一次如果日志在Connecting to 主机名 port 22之后就卡住那根本不是认证问题是端口不通。这时要看目标环境是否允许 22 端口出站。有些网络环境只放行常见的 Web 端口SSH 的 22 端口会被拦下来。这种情况的典型表现是超时而不是拒绝两者区别很重要拒绝说明主机可达但没服务在听超时说明连包都回不来。如果 22 端口确实不通很多代码托管服务提供备用端口如 443 复用或者改用 HTTPS 协议克隆。这是纯工程上的选择不存在孰优孰劣。第二步确认 ssh 用的是哪份程序、哪份配置。前面 1.2 说过用where.exe ssh和core.sshCommand确认。这一步经常能直接发现问题比如 Git 指向了一个早就被卸载的旧版本路径。第三步确认 ssh 递出的是哪把密钥。加上-v看日志里的Offering public key:。如果显示的指纹和你以为的不是同一把问题就在密钥选择上按 3.2 的第三条处理。第四步确认服务端是否接受了这把密钥。日志里出现Server accepts key说明服务端认可后面如果还失败多半是权限问题比如这把部署密钥只读你却在 push。没有这行就是服务端不认回到 3.2 逐条核对。第五步边界情况。少数环境会在认证之前要求用户确认访问规则或者对同一个 IP 的失败次数做限制。连续失败几次后会有短暂的静默期这时候再怎么重试都失败等一会儿再试反而通了。这个现象很容易被误判成配置错了实际只是被临时挡住了。一个非常有用的调试技巧是把详细日志落盘逐行读GIT_SSH_COMMANDssh -vvv git clone work-repo:team/demo.git 2 clone.log-vvv三个 v 能输出密钥协商、身份试探、认证方法的完整过程。日志可能几百行但真正要看的就那几个关键词用编辑器的搜索功能很快。4.2 Host key verification failed为什么首次连接之后还会出这个错known_hosts的存在意义是防中间人第一次连某主机时ssh 把对方的公钥指纹记下来之后每次连接都对比变了就报警。常见触发场景有三个一是首次连接但用了非交互环境。交互式终端会问Are you sure you want to continue connecting?你输yes就自动写入。但在脚本、CI、某些 IDE 的内置终端里没法交互ssh 就报Host key verification failed然后退出。解决办法是提前把主机指纹写进known_hosts命令是ssh-keyscan。不过要注意直接ssh-keyscan 主机名 ~/.ssh/known_hosts相当于无验证地信任第一次结果安全性弱于人工核对指纹。团队协作环境里通常由管理员统一下发指纹比自己扫更稳妥。二是主机真的换了密钥。服务端迁移、重装、更换证书都会导致指纹变化。这时候 ssh 会给出非常醒目的警告并明确告诉你这可能意味着有人在中间捣鬼。处理方式不是简单删掉重来而是先确认变更是否来自官方渠道。确认无误后删掉known_hosts里对应的那一行再连ssh-keygen -R 主机名这条命令会自动备份原文件生成.old后缀比手改安全。三是主机名解析到了不同的机器。比如同名主机在不同环境下指向不同 IP两台机器指纹不同。这种情况在切换网络环境时偶有发生表现是昨天还好好的今天突然报警。4.3 HTTPS 克隆的那几个坑证书、凭据与凭据过期HTTPS 协议的优势是开箱即用不需要配密钥代价是认证细节藏在 TLS 和 HTTP 两层里出错信息不如 SSH 直白。证书问题的典型报错是SSL certificate problem: unable to get local issuer certificate。原因通常是 Git 使用的证书链不完整或者机器时间不对。对 Windows 上的 Git for Windows一般会使用C:\Program Files\Git\mingw64\ssl\certs\ca-bundle.crt作为信任库。如果公司环境签发过内部根证书需要把它追加到这个信任库或通过http.sslCAInfo指定。git config --global http.sslCAInfo C:/certs/enterprise-root.crt有个反模式要特别提醒网上不少帖子教你git config --global http.sslVerify false来一键解决。这相当于把加密通道的身份校验彻底关掉数据是否被篡改就失去了保障。临时排查时用一次可以但绝对不要把它留在全局配置里。我用过一次后来在几个月后的安全审计里被翻出来尴尬得很。凭据问题的典型表现是反复弹窗要求输密码或者明明输对了还是 401。Windows 上 Git 通常配有 Git Credential Manager凭据存在Windows 凭据管理器里。当令牌更换、过期或权限变更后旧的凭据会一直失败而 Git 不会自动清掉它。清理方式git credential-manager reject https://repo.example-host.com或者打开控制面板 → 凭据管理器 → Windows 凭据手动删掉对应条目。这类问题特别容易发生在公司要求定期轮换访问令牌的环境里每隔一段时间就会重演一次记住路径就好。4.4 early EOF、index-pack failed大仓库克隆到一半崩掉这类报错和认证无关是数据传输或本地解包阶段的问题。特点是连接能建立进度条跑到某个百分比才炸。几个方向按顺序试降低单次传输体积。用浅克隆先拿到最新提交后续再按需补齐历史git clone --depth1 work-repo:team/demo.git对只想看代码、不需要历史的情况这招立竿见影。需要完整历史时再执行git fetch --unshallow补回来。调整传输缓冲区。某些网络路径上会出现写不进去的情况增大 HTTP 缓冲区有时能缓解git config --global http.postBuffer 524288000必须说清楚这个参数的作用经常被夸大到包治百病的程度。它只在特定的大包推送场景下有效对于频繁断连导致的early EOF帮助有限。真正的断连问题还是得从网络链路稳定性上找原因比如是否有中间设备做了空闲超时切断。给足本地资源。index-pack failed有时候是本地打包时的内存或磁盘问题。检查磁盘剩余空间检查 Windows 上路径长度限制。Git 默认受 MAX_PATH 260 字符约束深层目录的大仓库会因此报出莫名其妙的错误开启长路径支持git config --system core.longpaths true系统级配置需要管理员权限的终端。这个开关开启后很多克隆完成但检出失败的问题会直接消失。排查中断的时间规律。如果每次都在克隆到固定时长比如恰好 5 分钟时断开那基本可以确定是链路上有设备在做空闲或时长限制而不是 Git 的问题。这种时候换个时段、换个网络出口往往比改参数有效。5. HTTPS 与 SSH 的选择场景不同答案不同两种协议都能克隆、都能推送功能上等价。真正决定用哪个的是所在环境的约束和日常操作的便利性。维度HTTPSSSH首次配置成本低输账号令牌即可中要生成密钥并上传公钥认证凭据令牌有有效期需定期轮换密钥长期有效可撤销端口占用通常 443通常 22防火墙/网关友好度高443 普遍放行视环境而定22 可能受限交互式输入可能弹窗配好 agent 后无感多账号切换靠凭据管理器偶有串号靠 config 别名切换明确自动化场景需注入令牌需管理私钥文件我的实际用法是混合日常开发在固定几台机器上用 SSH config 别名一次配好长期省事多账户也不会串。在临时的、不受控的机器上比如借用的设备、一次性的构建环境用 HTTPS用完清凭据不留痕迹。还有个小技巧值得说Git 支持 URL 重写可以把某个前缀的地址自动改写成另一种协议。git config --global url.gitrepo.example-host.com:.insteadOf https://repo.example-host.com/配置之后无论从文档里复制的克隆地址是 HTTPS 还是 SSH实际都会走 SSH。这个功能在多项目、多脚本共存的环境里特别有用——你不用去改别人的脚本一条配置就把协议统一了。反过来写也成立把 SSH 前缀改写成 HTTPS适合临时切到免密环境。要注意insteadOf是前缀匹配写短了会影响一大片 URL。配置完用git config --global --get-regexp url复查一遍别留下拼错的条目在配置文件里作祟。6. 我日常沉淀下来的几个习惯6.1 打开调试开关比反复猜快十倍Git 有两组环境变量排查时几乎是必开的GIT_TRACE1 git clone work-repo:team/demo.git GIT_CURL_VERBOSE1 git clone https://repo.example-host.com/team/demo.gitGIT_TRACE会打印 Git 调起的每一个外部命令你能直接看到它到底执行了哪一行 ssh、带了哪些参数。前面反复强调到底用哪份 ssh开这个开关一次就能看到答案比查配置文件可靠。GIT_CURL_VERBOSE输出 HTTP 层的完整请求响应头看状态码、看重定向、看认证方式协商全都一目了然。遇到 401、403、407 这类状态码比看 Git 包装后的那句unable to access有用得多。这两个开关只在当前命令生效不会污染全局配置用完即走。6.2 那些不报错但会悄悄坑人的配置有几项设置不会让命令失败但会让协作出问题属于事后才发现的类型。core.autocrlf在 Windows 上默认可能是true提交时把 CRLF 转成 LF检出时再转回来。如果团队里有成员在别的平台上工作文件行尾不一致会导致整个文件被判定为全部修改diff 里刷满红绿。团队应该统一策略要么仓库里放.gitattributes明确定义要么所有人统一false并在编辑器里设置。靠默认值各管各的迟早出事。core.ignorecase在 Windows 上默认true因为 NTFS 大小写不敏感。这意味着仓库里同时存在Readme.md和readme.md时本地只会有一个另一个被静默覆盖看起来一切正常但推送时就会出问题。看到文件明明改了却提交不上去先怀疑这个。user.name和user.email配错提交记录里的作者就不对。在多人协作仓库里作者信息错了有时候会导致提交无法关联到账号影响工作记录统计。新机器初始化第一件事就该是git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global --list最后一行把全局配置全列出来看一眼心里有底。我在接手别人的机器时习惯先跑这一条经常能发现一堆历史遗留的奇怪配置。6.3 一份可复用的最小自检清单新机器装完环境、或者克隆报错时我会按这个顺序过一遍基本能覆盖八成情况git --version和ssh -V都正常输出版本。where.exe ssh只命中预期的那一份或core.sshCommand已显式指定。ls -la ~/.ssh能看到私钥和.pub权限正常。ssh -vT git主机别名日志里出现Authenticated或明确的失败原因。ssh-add -l里能看到目标密钥指纹。git config --global --list里没有sslVerify false这类危险项。主机名解析正常ping或nslookup能得到预期结果。这套清单的价值不在于全面而在于顺序——从有没有工具到工具是不是对的那份到凭据有没有生效到连接能不能建立正好对应前面那张分层图。哪一步断了问题就在那一层。我在好几台机器上来回折腾过这些配置最深的一点体会是大部分克隆失败不是 Git 的问题甚至不是 SSH 的问题而是你以为在用 A实际在跑 B这类环境错位。所以现在遇到报错我第一反应不是改配置而是先让环境自己说话——打印路径、打印版本、打印日志。把默认值摊开来看比凭经验猜要快得多。另外提醒一句凡是网上抄来的一键解决配置尤其是带false、--force、insecure字样的先想想它到底关掉了什么保护再决定要不要执行。