Windows on Jiangwan's Blog

解决 Windows 环境下 Git SSH Permission denied 报错

Mon, 30 Mar 2026 00:00:00 +0000

一、现象描述

在 Windows 环境下配置 GitHub SSH 密钥时，常常会遇到一个充满迷惑性的报错现象。当我们在终端直接测试 SSH 连接：

ssh -T git@github.com

终端会正常返回欢迎信息，证明密钥配置无误：

Hi your_username! You've successfully authenticated...

但紧接着执行 git clone 或 git push 命令时，却直接报错拒绝访问：

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

二、问题排查

现象表现为同一台电脑对同一份密钥的读取结果前后矛盾。为了确认 Git 在执行网络请求时到底发生了什么，我们可以开启 Git 的 SSH 调试模式。在终端临时注入环境变量，强制输出 Git 底层的 SSH 调用日志：

GIT_SSH_COMMAND="ssh -v" git clone git@github.com:your-name/your-repo.git

通过详细日志可以观察到，git clone 并没有调用系统默认的 SSH 程序，也没有去正确的 ~/.ssh 目录下寻找刚刚配置好的私钥。

三、原因分析

这个问题的核心在于：Windows 系统中同时存在两个互不相通的 SSH 程序。

  graph TD
    A[终端环境] --> B{执行指令}
    B -->|ssh -T| C[Windows 原生 OpenSSH]
    B -->|git clone| D[Git 自带内部 SSH]
    
    C -->|读取 C:\Users\用户名\.ssh| E[找到私钥]
    E --> F[连接 GitHub 成功]
    
    D -->|MSYS2 模拟环境| G[路径解析偏差 / 无法读取 ssh-agent]
    G --> H[找不到私钥]
    H --> I[Permission denied]

1. Windows 原生 OpenSSH

从 Windows 10 开始，微软内置了一套原生的 OpenSSH 工具，路径为 C:\Windows\System32\OpenSSH\ssh.exe。执行 ssh -T 时，系统默认唤醒的是这个原生程序。它能准确识别当前 Windows 用户的 ~/.ssh 目录并读取私钥，因此测试顺利通过。

2. Git for Windows 自带 SSH

安装 Git 时，为了兼容旧版 Windows，Git 官方打包了一个专属的 SSH 程序，路径通常在 C:\Program Files\Git\usr\bin\ssh.exe。执行 git clone 时，Git 会强制调用自带的内部 SSH。由于该程序运行在一个模拟的 Linux 环境 MSYS2 中，它对文件路径的解析或对 Windows 系统 ssh-agent 密钥代理服务的读取存在偏差。这导致它在连接 GitHub 时交不出密钥，从而被服务端拒绝。

四、解决方案

明确了问题是环境割裂导致的，修复逻辑就是统一底层调用。我们需要通过 Git 的全局配置，覆写它的默认行为，强制 Git 放弃内部自带的 SSH，转而调用 Windows 系统的原生 SSH 程序。

在终端执行以下配置命令：

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

执行完毕后，Git 的网络操作与系统的 ssh 命令彻底打通，底层调用的都是同一个能正确找到密钥的程序。再次执行 git clone 即可顺利拉取代码。

五、总结

在开发环境搭建中，多套工具链附带的同名依赖组件往往是引发底层冲突的根源。遇到配置生效不一致的情况，利用 GIT_SSH_COMMAND="ssh -v" 这类环境变量暴露出底层的真实调用路径，是打破信息差、快速定位问题的有效手段。

Node/npm/pnpm 安装指南

Wed, 18 Mar 2026 00:00:00 +0000

一、引言

在动手安装之前，我们先理清一个概念：Node.js 是一个 JavaScript 运行环境。当你安装 Node.js 时，它会“买一赠一”地在你的系统里捆绑安装官方的包管理器，npm (Node Package Manager)。

既然官方自带了 npm，为什么大家还要折腾？答案很简单：天下苦 node_modules 久矣。

1. npm 的痛点：曾经的“依赖黑洞”

早期的 npm 有几个让开发者头疼的缺陷：

极其占空间：每个项目都会在根目录下生成一个独立的 node_modules 文件夹。如果你有 10 个项目都用到了同一个库（比如 React），这个库就会在你的硬盘里被重复下载、完整保存 10 次。
速度慢：串行安装机制导致下载速度令人抓狂。

2. pnpm 的破局：硬盘空间魔法

pnpm（Performant npm）是目前开源社区最推荐的包管理器之一，它直接解决了上述痛点。

它巧妙地使用了计算机文件系统中的 硬链接（Hard link） 技术。无论你在电脑上创建了多少个项目，只要它们用到了同一个版本的某个包，pnpm 只会在系统全局的 Store 中保存一份实体文件，然后通过硬链接将它们映射到各个项目的 node_modules 中。

结论：极速的安装时间 + 极大地节省硬盘空间 = 无脑选 pnpm。

二、实战演练

如果你只是单纯地为了跑脚手架、装依赖，直接去官网下载安装包绝对是最省事的选择。

步骤一：官网直装 Node.js

打开 Node.js 官方网站。
强烈建议下载 LTS（长期维护版），不要去碰 Current（最新尝鲜版），能避免很多莫名其妙的兼容性报错。
下载对应的 .msi (Windows) 或 .pkg (macOS) 文件，双击运行，一路点击 Next 完成安装。

安装完成后，打开终端（CMD/PowerShell/Terminal），验证是否成功：

# 验证 Node.js
node -v

# 验证赠送的 npm
npm -v

步骤二：拯救 C 盘（修改 npm 全局路径）

这是无数 Windows 开发者痛彻心扉的踩坑点。 Node 本身装在 C 盘没关系，但 npm 默认会把以后所有全局安装的包和缓存文件都塞进 C 盘的 AppData\Roaming 目录下。时间一长，C 盘直接标红。

我们需要把这部分转移到 D 盘（或其他非系统盘）：

在 D 盘的 Node.js 安装目录下（或者你自定义的一个目录，比如 D:\nodejs），新建两个文件夹：node_global 和 node_cache。
打开终端，执行以下命令重定向路径：

# 设置全局模块的安装路径
npm config set prefix "D:\nodejs\node_global"

# 设置缓存路径
npm config set cache "D:\nodejs\node_cache"

致命踩坑点：配置环境变量。因为我们修改了全局安装路径，系统现在找不到你以后全局安装的命令了。你必须告诉 Windows 去哪里找：

右键“此电脑” -> 属性 -> 高级系统设置 -> 环境变量。
在“系统变量”中找到 Path，双击编辑。
新建一条，填入你刚才创建的全局路径：D:\nodejs\node_global。
一路点击“确定”保存，然后必须重启你的终端。

步骤三：配置镜像源与激活 pnpm

网络问题是国内开发者的共同阻碍，我们需要把 npm 的下载源切换到国内镜像：

# 设置淘宝镜像源
npm config set registry https://registry.npmmirror.com/

最后，利用刚刚配置好的 npm，全局安装并激活 pnpm：

# 全局安装 pnpm（它现在会被安装到 D:\nodejs\node_global 里）
npm install -g pnpm

# 为 pnpm 同样配置国内镜像源
pnpm config set registry https://registry.npmmirror.com/

# 验证安装
pnpm -v

至此，你的电脑不仅拥有了一个干净、极速、省空间的 pnpm 环境，还成功保卫了你宝贵的 C 盘容量。以后遇到任何项目的 npm install 指令，都可以愉快地替换成 pnpm install 了。