GitLab SSH 连接失败主因是本地密钥未被 GitLab 信任或 remote URL 仍为 HTTPS；需验证 ssh -T、修复权限、配置 ~/.ssh/config 主机别名，并确保 remote URL 使用 git@host:形式。
GitLab SSH 连接失败：先确认 ssh -T git@gitlab.com 能否通
多数连不上 GitLab 的问题，根本不在 VS Code 配置，而在本地 SSH 密钥压根没被 GitLab 信任。VS Code 只是调用系统 git 命令，它不管理密钥，也不改 ~/.ssh/config。
实操建议：
- 在终端运行
ssh -T git@gitlab.com（替换成你的 GitLab 地址，比如git@your.gitlab.internal），看是否返回Welcome to GitLab - 如果报
Permission denied (publickey)，说明密钥没加、没配对、或没上传到 GitLab —— 此时修 VS Code 没用 - 确认
ssh-agent已启动且密钥已添加：eval "$(ssh-agent -s)"+ssh-add ~/.ssh/id_rsa（路径按你实际密钥名调整） - 检查
~/.ssh/config是否为对应主机指定了正确的IdentityFile和User
VS Code 内 Git 操作仍走 HTTPS：检查 git remote get-url origin
VS Code 的源代码管理面板只是 git CLI 的图形界面，它不会自动把 HTTPS 地址转成 SSH。如果你 clone 时用了 HTTPS 地址，后续所有操作（拉取、推送、同步）都继续走 HTTPS，和 SSH 配置完全无关。
实操建议：
- 在项目根目录终端执行
git remote get-url origin，看输出是不是以https://开头 - 如果是，立刻换掉：
git remote set-url origin git@gitlab.com:username/project.git（注意格式：git@host:path，不是ssh://） - 换完后在 VS Code 里点「同步更改」或手动「拉取」，观察底部状态栏是否显示
origin而非报 401 - 别信「Git: Clone」命令的默认协议选择 —— 它可能仍推 HTTPS，务必手动核对 remote URL
git push 提示 Bad owner or permissions on /home/user/.ssh/config
这是 Linux/macOS 下典型权限错误。SSH 对私钥和配置文件权限极其敏感，VS Code 启动方式（比如从桌面图标点击）可能导致它继承了宽松的 umask，进而让 ssh 拒绝读取密钥文件。
实操建议：
- 修复权限：
chmod 600 ~/.ssh/id_rsa，chmod 644 ~/.ssh/id_rsa.pub，chmod 600 ~/.ssh/config - 确保
~/.ssh目录权限是700：chmod 700 ~/.ssh - 如果用 VS Code Desktop（.deb/.rpm/.pkg），尝试从终端启动：
code .—— 这样能继承 shell 的ssh-agent环境变量 - Windows 用户注意：WSL 中的密钥不能直接被 Windows 版 VS Code 读取；反之亦然，别混用
多 GitLab 实例共存：靠 ~/.ssh/config 主机别名隔离
公司内网 GitLab 和公网 GitLab 用同一用户名 git，但域名不同。不配 ~/.ssh/config，SSH 无法区分该用哪把密钥 —— git 用户名一样，ssh 就只认第一个匹配的密钥。
实操建议：
- 在
~/.ssh/config里为每个实例建独立段落，用 Host 别名区分：
Host gitlab-internal HostName your.gitlab.internal User git IdentityFile ~/.ssh/id_rsa_internal Host gitlab-cloud HostName gitlab.com User git IdentityFile ~/.ssh/id_rsa_cloud
- 然后把 remote URL 改成对应别名：
git@gitlab-internal:group/proj.git - VS Code 不需要额外设置 —— 它完全依赖底层
git和ssh行为 - 别用 IP 地址写 HostName，否则
ssh无法匹配 config 段落
~/.ssh/config 的 Host 别名是否被 remote URL 正确引用。 
