ssh agent转发在vscode中依赖终端环境而非配置，需从已启动agent的终端执行code .启动vscode，并确保forwardagent yes在对应host块中显式设置，windows用户须统一使用windows openssh代理。
SSH Agent转发在VSCode里根本不是配置出来的，是终端环境带进来的
VSCode本身不管理SSH Agent，它只是复用你当前终端（比如iTerm、Windows Terminal或WSL）已启动的ssh-agent进程和已加载的密钥。如果你在终端里能ssh user@host成功，但VSCode的Remote-SSH连不上，大概率是VSCode没继承到那个环境变量。
常见错误现象：Permission denied (publickey)、Agent admitted failure to sign using the key、或者Remote-SSH连接时反复弹密码框——其实不是密码错，是agent根本没被识别。
- 确保
ssh-agent已在终端中运行：eval $(ssh-agent -s)，再用ssh-add -l确认密钥已加载 - VSCode必须从该终端中启动：在终端执行
code .，而不是点击图标或Spotlight打开（macOS）、开始菜单（Windows）或桌面快捷方式（Linux） - Windows用户注意：WSL里启动
code才有效；PowerShell/CMD里启动的VSCode看不到WSL的agent - macOS上如果用了
launchd自动启动agent（如通过~/.zshrc里的ssh-agent -s），需额外用launchctl setenv SSH_AUTH_SOCK ...同步变量，否则VSCode GUI进程拿不到
Remote-SSH插件不读config里的ForwardAgent yes，得靠系统级SSH配置生效
很多人在~/.ssh/config里写了ForwardAgent yes，却以为Remote-SSH会自动启用转发——其实它只认全局默认行为，不会解析每条Host的细粒度配置。是否转发，取决于你连接时实际使用的SSH命令是否带-A参数，而Remote-SSH默认不加。
使用场景：需要在远程服务器上执行git clone git@github.com:private/repo.git，且不想把私钥拷到远端。
- 必须在
~/.ssh/config对应Host块里显式写ForwardAgent yes，仅Host *不够，Remote-SSH不继承通配规则 - 检查是否生效：连接后在远程终端执行
echo $SSH_AUTH_SOCK，有输出才说明转发成功；为空=没转 - 某些Linux发行版（如Ubuntu 22.04+）默认禁用agent forwarding，需确认服务端
/etc/ssh/sshd_config中AllowAgentForwarding yes且已重载sudo systemctl reload ssh - 安全提示：
ForwardAgent yes会让远程服务器能临时使用你的本地密钥——别在不可信主机上开
Windows下OpenSSH和Git for Windows的ssh-agent互不兼容
Windows用户最容易栽在这里：Git Bash自带的ssh-agent和Windows OpenSSH（即C:\Windows\System32\OpenSSH\ssh-agent.exe）是两套进程，socket路径、协议、甚至密钥格式都不互通。VSCode Remote-SSH默认调用系统OpenSSH，但你日常在Git Bash里ssh-add加的密钥，它根本看不见。
错误现象：ssh-add -l在Git Bash里能看到密钥，但在VSCode Remote-SSH连接的终端里ssh-add -l返回空；或者报错Could not open a connection to your authentication agent。
- 统一用Windows OpenSSH：任务管理器关掉Git Bash的
ssh-agent进程，改用Get-Service ssh-agent | Set-Service -StartupType Manual+Start-Service ssh-agent（PowerShell管理员运行） - 密钥必须用
ssh-add ~/.ssh/id_rsa（在PowerShell或CMD里执行），不能只在Git Bash里加 - WSL用户请直接在WSL内操作：
service ssh start+ssh-add，并确保VSCode是从WSL中用code启动的 - 别用PuTTY系列工具（Pageant）混搭——Remote-SSH不支持Pageant socket
转发成功后，私有仓库克隆仍失败？检查远程端的SSH_AUTH_SOCK权限和shell类型
即使echo $SSH_AUTH_SOCK有值，git clone还是提示Permission denied (publickey)，问题往往出在远程环境本身：socket文件权限不对，或者你用的shell（比如zsh）没正确继承环境变量。
典型场景：远程服务器是Ubuntu，你用bash登录没问题，但切换到zsh后git就失联agent。
- 确认socket文件可访问：
ls -l $SSH_AUTH_SOCK，属主必须是当前用户，且不能是root（常见于sudo su后残留） - zsh用户需在
~/.zshrc里补一句：export SSH_AUTH_SOCK（仅声明，不赋值），否则子进程可能丢变量 - 某些托管环境（如GitHub Codespaces、GitLab Runner）默认禁用agent forwarding，或限制
SSH_AUTH_SOCK路径，此时只能换用deploy key或token - Node.js脚本里调用
child_process.exec('git clone...')也可能丢失环境变量，需显式传入：{ env: { ...process.env, SSH_AUTH_SOCK } }
最常被忽略的一点：agent转发是逐跳生效的。如果你连的是A → B → C，而只在A→B开了ForwardAgent yes，那B上ssh C时C收不到agent——中间跳板机也得配ForwardAgent yes，且它的sshd得允许嵌套转发。
