Windows下Git安装配置与SSH密钥接入托管平台全流程指南

前段时间帮同事配置新电脑，又一次把 Git 从下载到 SSH 密钥串完了一遍。他中途问我的问题相当集中：官网下载的 Git 安装包为什么打开后选项这么多、环境变量到底要不要勾、配置完 SSH 之后Permission denied到底怎么排查。这些问题单独搜都有答案，但散落得到处都是。所以这次我干脆把整套流程整理成一篇完整的过程记录，覆盖 2026 年当前稳定版的 Git for Windows，从下载安装、环境配置到 SSH 密钥接入 GitHub、GitLab 等托管平台，每一步都写清楚“选什么”和“为什么这么选”。默认环境是 Windows 11，Win10 同样适用。

这篇内容适合零基础的新手，也适合已经用了 Git 一段时间但没认真整理过环境的同学。你没必要全部照抄，关键是看懂每一步背后的逻辑，比如git config --global和你本地的用户信息有什么关系、SSH 密钥的私钥到底给谁看、Windows 上换行符问题为什么会引发一整屏 warning。把这些逻辑搞明白，之后换电脑、换平台、换仓库配置都不会再发怵。

1. 安装之前，先搞懂 Git 在 Windows 里的几种打开方式

1.1 Git for Windows 不是一个孤立工具，它是一套环境集合

很多人第一次下载 Git 时，会以为下载的就是一个简单的命令行程序，装完双击打开一个黑窗口就能用。实际上 Git for Windows 安装包里包含的东西比想象中多，主要分成这几部分：

• Git 核心命令，也就是你平时敲的git clone、git commit、git push这些底层工具；
• Git Bash，一套模拟 Linux Bash 环境的终端，让你在 Windows 上也能用ls、grep、cat、ssh-keygen这类 Unix 风格命令；
• Git CMD，把 Git 命令封装到 Windows 命令提示符环境里；
• Git GUI，一个基础图形界面，日常我会用，但调试复杂问题还是在命令行更快；
• 默认的 SSH 客户端、SSL 库和 Windows 凭据管理器集成组件。

明白这一点很重要。之后你安装时看到的很多选项，其实都是在决定“要把这套环境里的哪几个部分以什么方式接入你的 Windows 系统”。选错不会让 Git 彻底不能用，但可能会让你在三周后在 VSCode 终端里突然敲不了git命令，然后一脸懵。

1.2 为什么 Git Bash 是 Windows 下最顺手的使用方式

现在 Windows 原生也支持在 CMD 或 PowerShell 里直接敲 Git 命令，很多人觉得没必要再装一个 Git Bash。我的实际体验是：新手优先用 Git Bash，尽量别用 PowerShell 去跑 Git 命令。

原因不是 Git 在 PowerShell 里跑不了，而是 Git Bash 里包含了和 Linux 服务器保持一致的那套 Shell 习惯。比如你在本地克隆一个仓库、写 shell 脚本、用/c/Users/你的用户名这种路径风格，都和服务器端思路统一。工作时遇到问题复制一条命令到本地，也不会因为 PowerShell 的引号转义规则不同而当场报错。

当然，VSCode 集成终端里直接选 Git Bash 作为默认 Shell 是更舒服的用法，这个到后面实操部分我会说到。先记住结论：安装时把 Git Bash 和让 Git 进入系统 PATH 的权利一起交给它，日常工作流就顺了。

2. 从官网下载到安装完成，每个步骤为什么这么选

2.1 下载渠道与版本判断

Git 的官方下载地址是https://git-scm.com/download/win。进入后网站会根据你的系统自动推荐 64 位版本，一般下载64-bit Git for Windows Setup即可。

网上有些第三方站点把 Git 打包发布，我不建议用。原因有三个：第一，版本可能滞后；第二，安装包是否被改过不好验证；第三，安装过程中可能捆绑额外的软件或修改主页。Git 本身是开源项目，官网已经提供了下载，没必要冒这个风险。

安装包分两种形态：

• 标准安装包（Setup），也就是双击运行、有图形向导的那一款；
• Portable 便携版，解压即用，不写入注册表，也不配 Windows 服务。

便携版适合装在 U 盘里临时用，但日常开发建议装标准版。标准版会把 SSH 客户端、凭据管理器、Git Bash 这些组件一起注册到系统里，体验更完整。

如果你本机已经装了旧版本，想升级到 2026 年最新稳定版，直接官网覆盖安装也行，前面的用户配置会保留。稍后我会给出一个更省事的 winget 升级命令。

2.2 安装向导里的重点选项

启动安装向导后，一路点 Next 会换来一个“能跑”的 Git，但里面有几个关键选项我建议你认真看一眼。逐个拆开说。

安装路径。默认是C:\Program Files\Git，建议保持默认。Git 不需要人为挪到 D 盘，安装在系统盘能避免一些权限管理上的奇怪问题。

选择组件。这里默认会勾选 Git Bash、Git GUI、OpenSSH、SSL 库、Windows 凭据管理器、文件系统缓存。我建议全部保持默认。特别说明两点：

• OpenSSH 不要取消勾选，否则后面用 SSH 密钥访问仓库会非常折腾；
• “Add a Git Bash Profile to Windows Terminal”这个选项，在较新版本里经常会出现在组件列表，建议勾上，装完后 Windows Terminal 里直接多一个 Git Bash 标签页。

默认分支名。这里会让你选择初始分支是master还是main，选main。GitHub、GitLab 新建仓库默认主分支现在基本都是main，本地也保持一致，以后少很多麻烦。

PATH 环境变量。这是最容易被新手选错的地方，有三个选项：

• 仅从 Git Bash 中使用 Git；
• 从命令行以及第三方软件中使用 Git（推荐）；
• 从命令提示符中使用 Git 并覆盖某些系统工具。

必须选第二个（Recommended）。选第一个会导致你在 CMD、PowerShell、VSCode 终端里输入git找不到命令，只能打开 Git Bash 用。选第三个会覆盖 Windows 自带的一些 Unix 工具，容易引发环境冲突。第二个的意思是让 Git 把自己加入系统 PATH，但不会去动系统原有的 CMD 命令，是最稳妥的。

SSH 可执行文件。Git for Windows 默认会带 OpenSSH，选择“使用捆绑的 OpenSSH”即可。如果你已经安装了 Windows 自带的 OpenSSH 客户端，并且专门配置过它，那可以选系统自带的，但对大多数开发者来说，选捆绑版本的一致性更好。

HTTPS 后端。一般保持默认的 OpenSSL 库。这个影响的是 Git 通过 HTTPS 协议访问远程仓库时用的 TLS 校验规则，日常使用 OpenSSL 足够。

行结束符转换。这一步非常容易踩坑，也是新手碰到一大堆 warning 的源头。默认选项是“在检出时转换为 Windows 风格，在提交时转换为 Unix 风格”，也就是core.autocrlf=true，我建议就按默认来。为什么？因为 Git 诞生在 Unix 环境下，仓库内部统一存LF换行，但 Windows 上的文本编辑器更喜欢CRLF，Git 就自动在你和仓库之间做转换。如果你在多人协作项目里用别的选项，很容易出现整个文件因为换行符不同被标记成改动的鬼故事。

终端模拟器。选择“使用 Mintty”还是“使用 Windows 默认控制台窗口”。我建议选 Mintty，也就是 Git Bash 默认的窗口。它的老式 Windows 风格更适合跑vim、显示颜色和快捷键。如果你更习惯 Windows 终端，这个选择也不会造成功能差异，后续反正可以把 Git Bash 集成进 Windows Terminal。

git pull默认策略，选择默认的 Fast-forward 或 merge 即可。git pull到底是 rebase 还是 merge 属于团队规范问题，不是安装阶段需要解决的问题。

额外选项中的“启用文件系统缓存”和“启用 Git 凭证管理器”建议都保持勾选。文件系统缓存对仓库文件的读取性能有帮助，凭证管理器决定 HTTPS 方式克隆时能不能记住密码。

符号链接。默认不启用。Windows 上的符号链接需要管理员权限，启用了反而会让普通用户在克隆带 symlink 的项目时不知所措。保持默认。

2.3 安装后的版本验证

安装完成后，打开 Git Bash，输入：

git --version

如果输出类似：

git version 2.47.1.windows.1

就说明 Git 核心已经生效。如果系统提示找不到命令，先检查安装时有没有选择第二项 PATH 环境变量，或者重启终端窗口让 PATH 重新加载。

再验证一下 SSH 客户端是否可用：

ssh -V

正常会输出类似OpenSSH_9.x的版本号。看到这个，后面配置 SSH 密钥就有基础了。

3. 装好后第一件事：用 git config 把身份理顺

3.1 user.name 和 user.email 决定提交记录长什么样

很多人装完 Git 就开始git clone，等到第一次git commit提交完，才发现提交者显示的是自己这台电脑的随机用户名，或者用了错误的邮箱。原因就在于 Git 不像某些商业软件那样强制要求你先注册，它默认从当前系统用户推导身份信息。

Git 里身份配置分三层：

• --system，影响这台机器上所有用户；
• --global，影响当前用户；
• --local，只影响当前仓库。

绝大多数情况下，我们要配的是--global。打开 Git Bash，执行：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这里有个非常实际的建议：邮箱最好和你使用的托管平台邮箱一致。GitHub 现在默认隐藏真实邮箱，但你的提交邮箱如果和 GitHub 账号无关，以后在贡献统计、README 自动生成的贡献者名单里可能会对不上。GitHub 比较推荐的是使用[e-mail]这个匿名邮箱，其他平台类似，但大多数人仍然会用自己的常用邮箱。

可以用下面的命令确认配置是否生效：

git config --global --list

如果后期在某个仓库里需要一个不同身份，就在那个仓库目录下用git config --local user.name "其他名字"覆盖。

3.2 换行符、默认分支、凭据管理器这几个配置要一起调

如果安装时选了推荐设置，那么core.autocrlf已经被设置为true，不需要再额外操作。但如果你安装了旧版 Git，或者直接手动改过配置，可以用这条命令统一：

git config --global core.autocrlf true

默认分支名也建议补一条，把初始分支固定成main：

git config --global init.defaultBranch main

这样以后在本地执行git init建出来的仓库就是 main，不会和远端仓库名字不一致。

接下来是 HTTPS 凭据管理。Git for Windows 新版本默认的凭据助手是manager，它会把密码或 Personal Access Token 存到 Windows 凭据管理器里，首次输入后，后续推送和拉取不再重复询问。你可以确认一下：

git config --global credential.helper

如果输出是manager，说明已经配置好。如果没有输出，手动加一句：

git config --global credential.helper manager

这套机制尤其适合用 HTTPS 方式克隆 GitHub/GitLab 仓库的同学。只要第一次输入 Token，之后 Git 自动读取 Windows 凭据管理器里的记录。

3.3 提升日常效率的 alias（可选但值得）

Git 本身命令不算短，常用操作可以给它们起个别名。我的做法是只加几个高频别名，不搞太花哨：

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm commit git config --global alias.lg "log --oneline --graph --all --decorate"

这样之后敲git st就是查看状态，git lg能看到一目了然的提交历史图。别把这套别名用得太重，否则换别的机器会不习惯。

4. SSH 密钥从生成到连接，一条龙

4.1 先检查是否已有密钥

SSH 密钥的本质是一对文件：私钥和公钥。私钥保存在你自己的电脑里，永远不要发给别人；公钥可以贴到 Git 托管平台的账号设置里，用来验证“持有对应私钥的人就是你”。

先看看本机是不是已经有密钥，避免重复生成导致后面混乱：

ls -la ~/.ssh

如果看到id_ed25519和id_ed25519.pub，说明之前生成过。如果看到id_rsa和id_rsa.pub，那是 RSA 密钥。你可以选择继续用现有的，也可以生成一套新的。为了统一管理，我更推荐生成一个新的 Ed25519 密钥。

4.2 用 ed25519 生成密钥，简单还省事

在 Git Bash 里执行：

ssh-keygen -t ed25519 -C "[e-mail]" -f ~/.ssh/id_ed25519

解释一下参数：

• -t ed25519指定密钥类型。Ed25519 是目前 SSH 里公认安全性和性能都比较平衡的算法，生成的密钥短，使用体验好；
• -C是注释，通常填你的邮箱，方便在托管平台上认出这把公钥；
• -f指定保存路径，~/.ssh/id_ed25519是惯例路径。

执行后会问你设置 passphrase（口令）。这一步建议认真想想，不要随手回车。passphrase 相当于给私钥再加一层锁，即使有人偷走了你的私钥文件，不知道口令也没法用。

如果你担心以后每次连接都要输口令，可以配合 ssh-agent 解决，下面会讲。个人建议是设置口令，同时启动 ssh-agent 让它帮你记住口令，兼顾安全和便利。

如果某些必须用 RSA 的旧平台不支持 Ed25519，再生成一个 RSA 密钥也行：

ssh-keygen -t rsa -b 4096 -C "[e-mail]" -f ~/.ssh/id_rsa

4.3 把私钥交给 ssh-agent，而不是反复输入口令

ssh-agent 是 SSH 官方提供的“钥匙串”服务。你把私钥加进去后，它会替你保管解密后的私钥会话，之后在同一终端会话里连接远程服务器时，不再要求输入 passphrase。

Git for Windows 安装时已经带了 ssh-agent 相关文件，但你需要手动启动它。在 Git Bash 里执行：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

第一条命令是启动后台 agent 进程，并设置相关环境变量。第二条命令把私钥加入 agent，输入一次 passphrase 后，本次会话内不会再问。

如果你希望 Windows 上的 Git Bash 每次打开都自动加载密钥，可以在~/.bashrc里加两行：

eval "$(ssh-agent -s)" > /dev/null ssh-add ~/.ssh/id_ed25519 2>/dev/null || true

但这种方式每次开终端都会弹一次 passphrase 输入，不算最好的体验。另一种更 Windows 原生的做法是使用 Windows 自带的 OpenSSH Authentication Agent 服务。以管理员身份打开 PowerShell，执行：

Set-Service -Name ssh-agent -StartupType Automatic Start-Service ssh-agent

然后把 Git for Windows 的 SSH 设置切换成使用 Windows OpenSSH。这里牵扯到两套 SSH 的共存问题，对普通开发场景我建议不要混用，要么一路用 Git 自带 OpenSSH，要么一路用 Windows 自带 OpenSSH。混用的最常见问题就是 agent 里明明有了密钥，Git 却就是认不到。

4.4 把公钥粘贴到 GitHub、GitLab 或其他托管平台

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

输出的内容以ssh-ed25519开头，后面是一长串字符串，最后是你的邮箱。这整行就是需要复制到平台上的内容。

具体添加路径：

• GitHub：进入 Settings → SSH and GPG keys → New SSH key；
• GitLab：进入 Preferences → SSH Keys；
• Gitee：进入设置 → SSH 公钥。

标题随便填一个能让自己认出来的，比如“Windows work laptop 2026”。公钥本身整行粘贴即可。

添加完成后测试连接。GitHub 主机名是github.com，用户名固定是git：

ssh -T [e-mail]

第一次连接会出现一段确认known_hosts的提示，问你是否确认来自 github.com 的指纹。输入yes回车。如果一切正常，GitHub 会返回类似：

Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access.

GitLab 的测试命令是：

ssh -T [e-mail]

能收到欢迎信息，就说明密钥链路已经打通。

4.5 用 ~/.ssh/config 管理多平台、多账号的密钥

如果你同时使用 GitHub、GitLab 和公司内网 GitLab，多把密钥就很容易冲突。SSH 默认会拿~/.ssh/id_ed25519去连接所有服务器，但某些平台需要用对应的另一把私钥。这种情况建议写一个~/.ssh/config文件。

示例：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519 Host gitlab.com HostName gitlab.com User git IdentityFile ~/.ssh/gitlab_ed25519 Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/gitee_ed25519

这样不同域名走不同私钥，互不干扰。配置完成后，还是用ssh -T [e-mail]这类命令验证。

还有一个常见场景：某台服务器不是 22 端口，而是 2222 端口。这种情况也可以在~/.ssh/config里加一行Port 2222，比每次在命令行手写参数方便得多。

5. Windows 下最容易翻车的问题：我的完整排查链路

5.1 Permission denied (publickey)，先查这三层

Permission denied (publickey)是 SSH 配置时出现频率最高的错误。我看到很多人的做法是在网上搜一条命令复制，但没解决问题。正确的思路是逐层排查。

第一层，看本机是否存在私钥，并且是不是你想要的那把：

ls -la ~/.ssh

如果发现没有密钥文件，说明压根没生成，回头执行ssh-keygen。

第二层，看 ssh-agent 里有没有加载这把私钥：

ssh-add -l

如果提示 The agent has no identities，说明私钥还没加进去，执行：

ssh-add ~/.ssh/id_ed25519

第三层，用 debug 模式看 SSH 真正发送给服务器的是什么：

ssh -Tvvv [e-mail]

重点看输出里Offering public key之后发生什么。如果出现了Authentication refused，说明服务器不认这把公钥，多半是公钥没有正确地贴到平台上，或者贴到了别的账号下。如果显示Permission denied出现在No more authentication methods to try前面，也说明服务器端没有绑定这把公钥。

还有一种情况是 Git 仓库本身用了 HTTPS remote，但你一直配 SSH 密钥。此时执行：

git remote -v

看到的是https://github.com/用户/仓库.git，那就和 SSH 密钥没有关系，要么把 remote 改成 SSH 地址，要么配置 HTTPS 凭据。很多人折腾半天 SSH，其实仓库地址还是 HTTPS，方向完全错了。

5.2 Host key verification failed 的完整处理

这条报错通常发生在更换过系统、重装过 Git、或者所连服务器的指纹变化之后。SSH 第一次连接某台主机时，会把主机公钥指纹写入~/.ssh/known_hosts。如果后来连接时指纹对不上，SSH 会认为中间有人劫持，直接拒绝继续。

你看到的典型报错是：

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

如果确定不是被劫持，只是服务器重装系统或者密钥变化，处理方式是删掉known_hosts里对应的旧记录：

ssh-keygen -R github.com

然后重新ssh -T [e-mail]，正常确认新指纹即可。如果希望更彻底地清掉所有 known_hosts，可以删掉整个文件，但不太建议，一次失误就会把常用服务器的指纹全清掉。

5.3 HTTPS clone 一直弹密码，或提示 403

GitHub 老早就不再支持用账号密码走 HTTPS 推送，所以当你的 Git 提示输入用户名和密码时，密码位置要填的不是登录密码，而是 Personal Access Token（PAT）。这个 Token 需要在 GitHub Settings → Developer settings → Personal access tokens 里生成，勾选repo、workflow等需要的权限。

拿到 Token 后，第一次通过 HTTPS 方式连接时，Git 会弹窗要求输入用户名和 Token。注意，用户名填你的 GitHub 用户名，密码填 Token。之后凭据管理器会记住这段关系。

如果已经填错导致凭据管理器里保存了错误信息，可以去 Windows 的“凭据管理器”里删除对应记录。搜索“凭据管理器”，在“Windows 凭据”列表里找到git:https://github.com或git:https://gitlab.com之类的条目，删除后重试。

5.4 VSCode 里提示 dubious ownership，仓库明明存在却打不开

这个坑在 Windows 上特别常见。报错类似：

Detected dubious ownership in repository at 'C:/Users/xxx/Projects/xx'

原因是 Git 安全策略认为当前 Git 进程的属主和仓库目录的属主不一致。常见触发场景包括：你用管理员身份打开过 Git Bash、VSCode 以管理员权限运行、或者目录是网络驱动器/移动硬盘映射过来的。

解决办法不是直接关闭安全策略，而是把特定目录加入白名单：

git config --global --add safe.directory "C:/Users/xxx/Projects/xx"

如果项目很多，也可以直接把整个项目根目录加进去。如果要加当前所在的仓库目录，可以先进入该目录再执行：

git config --global --add safe.directory "%CD%"

但%CD%在 Git Bash 里的写法不一样，Git Bash 用的是$PWD。建议直接把完整路径复制进去，省得踩转义的坑。

5.5 CRLF/LF 换行符 warning，能不能直接忽略

我刚配置 Git 时也以为warning: LF will be replaced by CRLF是可以忽略的，但它在团队协作里会造成很实际的影响。根本原因是不同成员的core.autocrlf配置不一致，导致明明只改了一行代码，却出现整个文件被标记为修改。

正确的做法分两步。第一步，在本地统一core.autocrlf true：

git config --global core.autocrlf true

第二步，在仓库根目录添加一个.gitattributes文件，把换行符规则固化到仓库里，这样团队所有成员不管本机怎么配置，都会遵守仓库规则。一个最简示例：

* text=auto *.sh text eol=lf *.bat text eol=crlf *.jpg binary

用.gitattributes的好处是，它就像写在项目内部的“换行符法律”，从源头上避免个人配置不一致引发的鬼故事。

6. 让 Git 在 Windows 下更好用的几个进阶配置

6.1 用 winget 安装和升级，避免每次官网手动下载

Git for Windows 本身有自动更新，但它不会静默升级。2026 年的 Windows 上，我反而更推荐用 winget 来安装和升级：

winget install --id Git.Git -e --source winget

以后升级：

winget upgrade Git.Git

优点是升级记录、卸载都更系统化，对于要管理多台 Windows 机器的人来说省事很多。如果公司环境不允许用 winget，再回到官网手动下载安装也完全没问题，两条路本质安装的是同一个软件。

6.2 大仓库提速：文件系统监视器与后台维护

Git 在 Windows 上处理超大仓库时，最明显的问题是状态查询慢、文件多的时候git status要转好几秒。新版本 Git for Windows 已经支持用文件系统监视器，可以开启：

git config --global core.fsmonitor true git config --global core.untrackedcache true

第一条开启后，Git 会借助 Windows 文件系统的变更事件来实时了解文件状态变化，而不是每次执行git status全量扫描目录。第二条是减少对未跟踪文件的重复扫描。这两个配置协同作用，在大仓库里的提速体感很明显。

进一步的自动化维护可以执行：

git maintenance start

Git 会在后台定时维护仓库对象，比如自动清理冗余数据、优化提交图。尤其是在 Windows 笔记本上，合盖休眠频繁，后台维护比手动git gc靠谱。

6.3 在 Windows Terminal 和 VSCode 里把 Git Bash 用顺手

装完 Git 后最值得做的联动之一，是把 Windows Terminal 的默认终端改成 Git Bash。如果你的安装包勾选了对应组件，Windows Terminal 会直接多出一个Git Bash配置。打开 Windows Terminal，点标签栏的下拉箭头，选设置，在配置文件列表里找到 Git Bash，设为默认即可。

在 VSCode 里，按Ctrl + Shift + P打开命令面板，输入Terminal: Select Default Profile，选择Git Bash。这样以后 VSCode 内置终端就是 Bash 环境，你既可以敲git命令，也能用ls、grep这些 Unix 风格命令。

有个小细节：如果 VSCode 集成终端里的 Git Bash 打开后出现中文乱码，多半是系统区域设置不是 UTF-8，或者终端字体不支持中文。把 Windows 区域设置里的“Beta：使用 Unicode UTF-8 提供全球语言支持”打开能解决大部分问题，但这会影响系统全局行为，改动前建议先确认不是字体问题。

6.4 给你的 .gitconfig 留一段可复用的模板

整篇内容落到最后，我建议你维护一份属于你自己的~/.gitconfig。以下是我在 Windows 机器上的一个比较克制的模板，你可以按需调整：

[user] name = Your Name email = [e-mail] [init] defaultBranch = main [core] autocrlf = true editor = code --wait fsmonitor = true untrackedcache = true [credential] helper = manager [alias] st = status co = checkout br = branch cm = commit lg = log --oneline --graph --all --decorate

其中editor = code --wait表示把 VSCode 当作 Git 的默认提交信息编辑器。如果没装 VSCode，可以先保持默认，也可以用notepad，不过体验会差很多。

我自己一直保持这样的习惯：每次新电脑配完 Git，第一件事是git config --global --list把配置拉出来看一遍，确认身份、autocrlf、credential.helper 都在。配置 SSH 后一定先用ssh -T验证，绝不直接去 clone 一个仓库试。这个验证成本很低，但能帮你把“网络问题”和“认证问题”在第一步就区分开。

如果你在这些步骤里卡住了，优先按照上面的排查链路去定位，不要急着删掉.ssh目录重来。键可以重新生成，但搞清楚错在哪一层，下次遇到同样的问题就能直接绕过。