ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

VSCode Remote SSH 连接失败排查指南:从 SSH 到 VSCode Server 全链路

VSCode Remote SSH 连接失败排查指南:从 SSH 到 VSCode Server 全链路 你有没有遇到过这种情况上午还在用 VSCode Remote SSH 连着服务器写代码下午突然就卡在 “Setting up SSH Host” 的弹窗上或者干脆给你一句Could not establish connection to xxx。更气人的是配置文件没动过、密码也没记错、服务器也重启过了可它就是连不上。我前后帮同事和自己排查过不下二十次这类问题每次原因都不重样有本地 SSH 客户端版本太老的有远端磁盘满了导致 VSCode Server 装不上的有密钥文件权限不对被 SSH 直接拒掉的还有 config 文件里一个不起眼的参数写错导致走了错误端口的。Remote SSH 这个功能好用是好用但它的链路比想象中长得多本地要发起 SSH 连接远端要启动 sshd 服务还要在服务器上安装和运行 VSCode Server任何一个环节出了岔子最终表现都是“连不上”。这篇文章我把自己踩过的坑和排查过的案例完整整理出来从网络层、SSH 认证层、VSCode Server 层三个维度逐个拆解每个问题都给出具体的操作命令和解决步骤。不管你是刚接触 Remote SSH 的新手还是已经被这个问题折磨了好几天的老手照着这篇文章的排查顺序走一遍大概率能自己搞定。1. 先把问题想清楚Remote SSH 到底卡在哪一环很多人在排查 Remote SSH 问题时容易陷入一个误区一看到错误弹窗就疯狂百度错误关键词然后照着别人的方案一顿乱改改了不行再搜下一个。这样做运气好能碰上答案运气不好就把自己的 SSH 配置越改越乱。我见过最夸张的一个同事为了修连接问题在 config 文件里加了七八个参数最后连密码登录都进不去了。其实 Remote SSH 的连接过程是可以拆解的。一条完整的连接请求要经过下面这几步本地 VSCode 调用本机的 SSH 客户端按照 config 文件里的配置找到目标主机的 IP 和端口。SSH 客户端与远端服务器的 sshd 服务建立 TCP 连接。双方确认认证方式密码或者密钥完成身份验证。验证通过后SSH 客户端在远端执行一条命令检查或安装 VSCode Server。VSCode Server 启动后本地 VSCode 与远端 Server 建立通信隧道把界面、插件、终端都“搬”到本地。这五步里前两步属于网络层第三步属于 SSH 认证层后两步属于 VSCode Server 层。绝大多数连接失败根源都在其中某一层。所以正确的排查思路应该是逐层验证定位到具体卡在哪一步再针对性地解决而不是盲目改配置。1.1 先对号入座常见错误现象速查不同环节出问题VSCode 给你的反馈其实是不一样的。我把最常见的现象整理成了一个对照表你可以先看一眼自己属于哪种情况现象最可能的环节典型原因卡在 “Setting up SSH Host” 很久没反应VSCode Server 层服务器无法下载 vscode-server或下载极慢弹出Could not establish connection to xxx网络层 / 认证层端口不通、用户名错误、认证失败统称反复要求输入密码但密码是对的认证层输错密码、服务器禁止密码登录、键盘布局问题报Host key verification failedSSH 认证层服务器重装过系统本地 known_hosts 里的指纹对不上连接成功后没多久就断开认证层 / 网络层服务器配置了空闲超时或网络不稳定提示Remote host identification has changedSSH 认证层服务器指纹变了IP 被重新分配或重装系统报Bad owner or permissions on ~/.ssh/config认证层config 文件权限不对SSH 拒绝读取这个表不是让你直接照抄解决方案而是帮你快速判断应该优先排查哪个方向。比如报 “Host key verification failed”你花两个小时去清服务器的 sshd 配置方向就错了清本地的 known_hosts 文件才是正解。类似地如果卡在 “Setting up SSH Host”你去检查密钥配置也没用问题大概率在 VSCode Server 的安装环节。1.2 三层排查法推荐的标准操作顺序我自己总结了一套排查流程每次遇到连接问题都按这个顺序来基本能把解空间缩小到很小的范围第一步用系统自带 SSH 客户端直接连接目标服务器绕开 VSCode。如果命令行里的ssh能连上说明网络和认证没问题问题在 VSCode Server 层如果命令行也连不上就可以专心排查网络和认证。第二步命令行连不上的情况下用ssh -v或ssh -vvv看详细日志找到具体的错误点。日志里有足够的信息告诉你是在 TCP 连接阶段失败的还是在认证阶段失败的。第三步如果命令行能连上但 VSCode 连不上登录服务器查看.vscode-server目录的状态检查日志文件。VSCode Server 的问题一般都能在~/.vscode-server/下找到线索。这套方法的核心逻辑是“降级排查”先把 VSCode 这层复杂封装剥掉用最原始的 SSH 工具做验证再用详细日志定位。后面几个章节我会按这个顺序一步步展开。2. 打牢地基把纯 SSH 连接先跑通再谈 VSCode很多 Remote SSH 连接问题本质上不是 VSCode 的问题而是本机或服务器的 SSH 环境有问题。VSCode 只是把 SSH 客户端包了一层图形界面底层调用的还是你电脑上的ssh命令。所以当连接失败时第一件事永远是打开终端手动执行 SSH 命令验证。2.1 本地环境检查确认 SSH 客户端可用在 Windows 上现在系统通常自带 OpenSSH 客户端。但我也遇到过不少机器尤其是公司统一安装的精简版系统自带的 OpenSSH 版本很老或者干脆没启用。先打开 PowerShell 或 CMD执行ssh -V如果显示类似OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2这样的版本信息说明客户端没问题。如果提示ssh 不是内部或外部命令就需要在系统的“可选功能”里启用 OpenSSH 客户端。操作路径是设置 → 应用 → 可选功能 → 添加功能 → 搜索 “OpenSSH 客户端” → 安装。装上之后重新开一个终端窗口再跑一次ssh -V确认。顺带说一句我见过有人因为本地 ssh 客户端版本过旧导致和远端的密钥交换算法不兼容报错提示是no matching key exchange method found。这种报错在升级客户端之后自然就好了。所以如果你的 SSH 版本比较老建议先升级不要急着找别的“偏方”。2.2 远端 sshd 服务状态与端口连通性测试确认本地客户端没问题后接着确认远端服务是否在监听。你可以在任意一台能访问该服务器的机器上执行telnet 服务器IP 22或者nc -vz 服务器IP 22如果端口通了会提示连接成功如果没通会提示超时或拒绝连接。这里要特别说明端口通不等于 SSH 能连上但端口不通基本上后面就不用看了一定是网络或服务的问题。登录服务器如果还能通过其他方式登录的话执行systemctl status sshd以及确认端口监听状态netstat -tlnp | grep :22如果 sshd 没在运行启动一下再试。如果是云服务器还要检查安全组规则确认 22 端口是否对本地 IP 开放。这个很多人容易忽略本地网络环境变了比如换了 Wi-Fi 或者去了公司出口 IP 变化后原来的安全组规则可能就不适用了。还有一个比较隐蔽的情况服务器上的 Fail2ban 这类工具把本地 IP 拉黑了表现同样是连接超时或拒绝。判断方法是换一台设备或者用手机热点连接试试如果能连上基本可以确认是 IP 被临时封禁。2.3 认证方式对比密码登录与密钥登录网络层打通之后接下来要看认证层。Remote SSH 支持两种认证方式密码登录和密钥登录。密码登录最大的问题是每次连接都会要求输密码而且有些服务器为了安全会限制密码登录次数、增加登录延迟体验很差。另外 VSCode 在密码登录态下虽然会缓存凭据但偶尔也会出现明明密码是对的、却提示认证失败的情况。我自己就遇到过几次最后发现是登录界面弹出时焦点没在输入框里密码被输到了别的地方。密钥登录是更推荐的方式。它把认证过程从“人输密码”变成“机器验指纹”不需要每次手动输入也更安全。SSH 密钥对是一对非对称加密的公钥和私钥公钥放服务器上私钥留在本地。连接时服务器会用一个随机数加密挑战只有持有对应私钥的客户端才能正确应答。2.4 生成密钥并部署到服务器在本地执行下面的命令生成密钥对ssh-keygen -t ed25519 -C your_emailexample.com这里我推荐用ed25519算法它的密钥更短、安全性高、验证速度快。如果远端服务器的 SSH 版本过老不支持 ed25519再用rsa -b 4096也可以。生成过程中会问你保存路径和 passphrase。路径直接回车用默认的~/.ssh/id_ed25519就行。passphrase 建议设置一个就算私钥文件泄露了别人没有 passphrase 也用不了。设置 passphrase 后Windows 的 OpenSSH 会借助系统凭据管理器记住这个口令之后连接不需要反复输入很省事。生成完后再把公钥传到服务器上ssh-copy-id -i ~/.ssh/id_ed25519.pub userserver_ip这个命令会自动把公钥追加到服务器上对应用户的~/.ssh/authorized_keys文件里。如果服务器不允许ssh-copy-id执行也可以手动操作把本地公钥内容复制下来登录服务器后写入~/.ssh/authorized_keys。注意目录和文件的权限要求chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys很多人在这一步踩坑公钥写进去了但目录权限是默认的 755 或 644SSH 出于安全策略会直接忽略这个公钥然后继续要求输密码也不给明确报错。这个很坑但解决办法就一行 chmod 的事。为了验证密钥是否生效执行ssh -i ~/.ssh/id_ed25519 userserver_ip如果直接登录成功不再要密码就说明密钥认证配置正确。2.5 config 文件的正确姿势这些参数很有用密钥配好之后我强烈建议在本地~/.ssh/config文件里把主机信息管理起来。直接用 IP 连接比较原始而 config 文件可以给服务器起别名、指定端口、指定密钥文件避免每次输一大串参数。比如这样一个配置Host my-server HostName 192.168.1.100 User root Port 22 IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 60 ServerAliveCountMax 3Host是别名在 VSCode Remote SSH 的输入框里填写的就是这个别名。HostName填真实 IP 或域名。User指定登录用户名。Port非默认端口时必填。IdentityFile指定用哪把私钥。ServerAliveInterval 60表示每 60 秒发一个 keepalive 包防止长时间没有操作被服务器断掉连接。在 Windows 上还有一个很坑的点如果你用多个 Windows 用户账号登录过同一台机器config 文件的所有者不对也会导致 SSH 直接报错。具体报错是Bad owner or permissions on C:\Users\xxx\.ssh\config。解决方法是右键 config 文件 → 属性 → 安全只保留当前用户和系统账户的权限删除其他人的权限。另外多主机配置时我习惯把所有服务器放在同一个 config 文件里用Host区分。VSCode 的 Remote SSH 扩展会自动读取这个文件连接时就很有条理。手动测试通过ssh my-server能直接登录之后再回到 VSCode 里尝试连接。这时如果还连不上问题基本就在 VSCode Server 这一层了。3. VSCode Server 才是大头装不上、起不来、连不上都在这如果你手动用 SSH 登录服务器毫无压力但 VSCode Remote SSH 依然失败那十有八九是 VSCode Server 的问题。VSCode Server 是 VSCode 在远端服务器上运行的一个后台服务负责在服务器端处理代码编辑操作、插件运行和终端会话。本地 VSCode 的图形界面只是一个“遥控器”真正干活的其实是服务器上的那个服务所以它装不上、起不来本地界面自然一片空白或者报错。3.1 首次连接时 VSCode Server 的安装过程理解 VSCode Server 的安装机制是排查问题的前提。当你第一次通过 Remote SSH 连接一台服务器时VSCode 会做这么几件事从微软官方服务器下载一个和你本地 VSCode 版本对应的vscode-server-linux-x64.tar.gz文件。把这个压缩包传到远端服务器的~/.vscode-server/bin/commit-id/目录下。解压并启动 server 进程。本地与远端 server 建立连接。这里的commit-id是 VSCode 版本的唯一标识。举个例子你本地 VSCode 是某个具体版本对应的就是一个确定的 commit-id。如果服务器上已经存在这个目录VSCode 会直接使用如果不存在或校验失败就会重新走一遍下载解压流程。了解了这个过程你就明白为什么很多问题会集中在“下载”这一步了。如果服务器到微软官方下载地址的网络不好VSCode 就会一直卡在 “Setting up SSH Host”进度条半天不动最后报超时或者干脆失败。3.2 高频故障下载失败、残留损坏、磁盘不足我在实际排查中遇到的 VSCode Server 问题主要集中在下面几类第一类下载失败或下载超慢。表现是连接时卡在 “Setting up SSH Host”过几分钟后提示失败。排查方法是在服务器上手动执行下载命令测试下载速度wget https://update.code.visualstudio.com/commit:commit-id/server-linux-x64/stable如果速度很慢或者直接超时就说明服务器到官方下载源的网络链路有问题。解决办法是在本地能正常下载文件的话先手动下载再传到服务器上解压到对应目录。操作顺序在本地把.tar.gz文件下载好。通过scp或sftp传到服务器比如/tmp/vscode-server-linux-x64.tar.gz。登录服务器执行mkdir -p ~/.vscode-server/bin/commit-id tar -xzf /tmp/vscode-server-linux-x64.tar.gz -C ~/.vscode-server/bin/commit-id --strip-components1这里注意--strip-components1的参数解压出来的目录结构通常是vscode-server-linux-x64/下面直接是文件和文件夹不加这个参数会导致目录层级多一层VSCode 找不到启动文件。第二类服务器上残留了损坏的 VSCode Server。有时候上次连接异常中断server 目录里的文件不完整。VSCode 检测到目录存在就不会重新下载但启动时又因为缺文件起不来。解决办法就是把目录删掉让它重新下载rm -rf ~/.vscode-server删掉之后重新连接。这个操作不会影响服务器上你的项目文件和代码里面只是 VSCode Server 的运行文件可以放心清理。第三类磁盘空间不足。VSCode Server 虽然不算大但加上插件和 Node 进程几百 MB 甚至 1GB 以上都是正常的。如果服务器磁盘满了连接会在“启动 Server”阶段失败。执行df -h看看磁盘使用率。我遇到过一台服务器根目录打到 98%VSCode Server 一直起不来清了日志和旧的 npm 缓存之后就好了。第四类版本不匹配。本地 VSCode 自动更新后commit-id 会变服务器上旧版 server 目录还在但新的下载失败。这种情况通常会伴随Version mismatch之类的日志。解决办法同样是清理~/.vscode-server或只删对应版本的目录让 VSCode 重新部署。3.3 看日志是核心技能VSCode Server 日志查看指南很多问题在界面上看不到细节但日志里写得很清楚。VSCode Remote SSH 的日志可以通过命令面板调出来CtrlShiftP输入 “Remote-SSH: Show Log”。这个日志文件在本地记录的是整个连接过程中 VSCode 与远端 server 的交互信息。包括本地执行了哪些命令、远端返回了什么输出、下载了哪个文件、解压到哪个目录、启动了什么进程全部都有。服务器端也有日志通常在~/.vscode-server/.commit-id.log或者~/.vscode-server/data/logs/目录下。登录服务器后tail -f ~/.vscode-server/.*.log可以实时观察连接时的日志输出。我在一次排查中就是靠一条日志发现服务器上的~/.vscode-server目录的所有者变成了另一个用户导致当前用户无法写入新文件。VSCode 界面上只显示了一个模糊的错误而日志里有一句EACCES: permission denied。所以建议大家遇到问题先看日志尤其是权限类的错误它很少会直接显示在界面上。3.4 Remote SSH 连接的 window 标题技巧在多次连接过程中很多人可能没注意到 Remote SSH 窗口左下角的绿色连接状态栏。当你连上服务器后左下角会显示当前连接的主机别名点击它可以快速切换服务器、断开连接或打开新窗口。这个区域同时也是排查问题的入口点击它会弹出 Remote SSH 的常用命令面板入口。在实际操作中遇到连接不上的情况我经常用到的是Remote-SSH: Kill VS Code Server on Host...这个命令。它的作用是强制结束服务器上的 VSCode Server 进程。有时候 server 进程卡死了新连接会一直等待旧的进程让出端口杀掉之后就能顺利重连。这个命令在 “Remote-SSH” 的主命令列表里可以找到执行时会让你选择要杀哪个主机上的 server。这比手残删目录要温和得多也足够解决大部分“Server 卡死”类的问题。另外如果你在一个服务器上切换过多个本地 VSCode 版本服务器上可能堆积了好几个版本的 server 目录。在命令行里执行ls ~/.vscode-server/bin/可以看到所有已安装的版本目录。手动清理掉不用的旧版本目录也能避免一些版本冲突带来的奇怪问题。4. 高频错误速查表与几个长期可用的技巧到这里排查链路基本走完了从网络到 SSH 认证再到 VSCode Server。最后我把平时遇到的高频错误做了一个速查表再分享几个能让 Remote SSH 用起来更顺手的配置项。4.1 错误信息速查表这个表是我在实际项目中反复验证过的每一行都对应过一次真实故障错误信息原因分析解决方案Could not establish connection to xxx连接任何一环节失败VSCode 统一显示的提示点 “Show Log” 查看详细日志定位具体环节Host key verification failed本地的 known_hosts 与服务器实际指纹不一致执行ssh-keygen -R ip清除旧指纹后重连Permission denied (publickey,password)认证失败可能是密码错误或密钥未被接受用ssh -v查看认证尝试过哪些方式检查密钥权限Bad owner or permissions on ~/.ssh/configWindows 下 config 文件所有者不是当前用户在文件属性的安全选项中只保留当前用户权限no matching key exchange method found本地 OpenSSH 客户端版本过老与服务器算法不匹配升级本机 OpenSSH或在 SSH 命令中指定兼容算法Remote host identification has changed服务器重装系统或 IP 被重新分配先确认当前服务器确实是目标机器再清除旧的 known_hosts 记录Failed to download VS Code Server服务器无法访问官方下载地址或下载中断手动下载 server 包上传解压或删除目录重试EACCES: permission denied服务器上 vscode-server 目录权限不对chown -R给当前用户或删掉目录重建这个速查表适合是当“字典”用遇到报错先来这里找一圈没有再去翻日志。我每次写文章或者录视频都会引用这个表因为它覆盖了最常见的 80% 场景。4.2 保持连接不断线的配置Remote SSH 用了很久的老用户一定会遇到一个问题连接一段时间没用再回到 VSCode 时候就断线了提示重新连接。断线的原因通常是网络设备把长时空闲的 TCP 连接回收了或者服务器端设置了空闲断开策略。解决办法有两个方向第一个方向是在本地~/.ssh/config里加保活参数Host my-server ServerAliveInterval 60 ServerAliveCountMax 3ServerAliveInterval表示客户端每 60 秒给服务器发一个保活包ServerAliveCountMax表示如果连续 3 个保活包没有收到回复就认为连接已断开。加了这两个参数之后即使你开着 VSCode 去吃饭、开长会只要电脑没有休眠连接基本都能保持住。第二个方向是检查服务器端的 sshd 配置。在服务器的/etc/ssh/sshd_config里看有没有ClientAliveInterval和ClientAliveCountMax参数。如果设置了较短的ClientAliveInterval服务器会主动断开空闲连接。可以通过调整这些参数来避免断线。4.3 几个冷门但管用的配置小技巧最后分享几个不容易注意到、但在特定场景下非常管用的配置。第一个是Remote.SSH: Show Login Terminal的设置。这个选项开启后VSCode 会弹出一个集成终端窗口展示 SSH 登录过程。如果你遇到“一直让你输密码但输完又说失败”的情况打开这个选项就能看到完整的认证交互过程定位问题准确得多。在 VSCode 设置里搜索Remote.SSH: Show Login Terminal勾选开启即可。第二个是Remote.SSH: Use Local Server的设置。默认情况下 VSCode 会把 Remote SSH 的界面服务运行在远端如果你的网络延迟很高操作会感觉卡顿。开启这个选项后界面服务会运行在本地网络延迟的影响会小很多。对于跨地域开发场景这个开关能明显改善体验。第三个是关于代理跳板机的场景这里是正经的跳板机场景用于公司内网运维如果目标服务器不能直接访问而是需要通过一台跳板机中转可以在 config 文件里这样写Host jump HostName 192.168.1.1 User admin Host target HostName 10.0.0.5 User root ProxyJump jumpProxyJump的意思是先 SSH 连接到jump这台机器再通过它转发到target。有了这个配置VSCode Remote SSH 直接连target即可它会自动走跳板机。这在公司内网环境里非常实用不需要每次手动做端口转发。第四个是关于公钥私钥不匹配导致的诡异现象如果你本地~/.ssh/下同时存在多个私钥文件SSH 默认会按顺序尝试。如果第一个私钥比如默认的id_rsa和目标服务器不匹配而匹配的私钥排在后面有些 SSH 版本会在尝试完所有密钥之前就被服务器拒绝。解决方法是 config 里明确指定IdentityFile或者用IdentitiesOnly yes防止 SSH 把 config 之外的密钥一并尝试。这些技巧单独看都不起眼但积累起来能在关键时刻帮你省下好几个小时的排查时间。尤其是ServerAliveInterval和ProxyJump一个解决日常断线问题一个解决网络架构问题属于那种“用过就回不去”的配置。5. 写在最后把这些经验变成你的排查本能总结一下我这几年用 Remote SSH 的真实体会。这个工具本身非常强大但它有一个特点一旦出问题错误信息往往非常模糊。VSCode 为了用户体验把底层真实的错误细节都藏了起来只在界面上显示一句“Could not establish connection”这导致很多人解决问题的速度完全取决于“有没有搜到相同的报错”。我个人的建议是把排查的思路固化下来不要每次都从零开始。先用ssh -v命令行验证确认是网络/认证/Server 哪一层的问题再看日志找到具体的报错关键词最后对照速查表定位解决方案。这套流程熟练之后绝大多数问题 5 分钟之内就能定位。另外养成一个好习惯每次成功解决一次连接问题后把原因和解决方式记下来。我自己的笔记本里已经积累了十几条 Remote SSH 的排障记录每次再遇到同类问题翻一下笔记比重新上网搜要快得多。你也可以把本文提到的速查表和操作步骤保存下来作为自己的第一份排障手册。工具会更新连接流程会变但“逐层定位、看日志、验证修改效果”这套思路什么时候都不过时。
返回列表