记一次 CentOS 7 无法使用新版 VS Code Remote-SSH 的处理方法

最近看到一篇关于 CentOS 7 无法使用新版 VS Code Remote-SSH 的文章，评论区有人提到了一个项目：

vscode-server-centos7

我顺着官方文档和这个项目看了一遍，把这件事记录下来，方便以后再遇到类似服务器时查。

问题是怎么来的

CentOS 7 自带的 glibc 版本通常是 2.17。新版 VS Code Remote-SSH 安装到远程服务器上的 VS Code Server，则要求更高版本的运行环境。

按照 VS Code 官方文档，目前这条兼容路径涉及的基础要求包括：

• kernel >= 4.18
• glibc >= 2.28
• libstdc++ >= 3.4.25
• binutils >= 2.29

从 VS Code 1.99 开始，官方分发的预编译 Server 只面向 glibc 2.28 及以上的 Linux 发行版。CentOS 7 的 glibc 2.17，自然就不在支持范围内了。

实际表现一般是：

• 本地 SSH 命令可以正常登录
• VS Code Remote-SSH 卡在 Installing VS Code Server
• 连接建立后马上断开，然后不断重试
• 日志里出现 GLIBC_2.28、GLIBCXX 或 server prerequisites 相关错误

这不是 SSH 本身的问题，而是远端 VS Code Server 启动时，动态链接库版本不满足要求。

不要直接替换系统 glibc

CentOS 7 还能正常运行，说明系统里大量命令和服务都在依赖现有的 glibc。

直接把 /lib64 下的系统库替换成自己编译的版本，风险非常大。轻则某个命令运行异常，重则 SSH、yum、systemd 甚至系统启动都可能受到影响。

这类问题更合适的处理方式是：

给 VS Code Server 准备一套单独的新运行库，只让它使用这套库，不动系统原有环境。

官方文档也给了类似的 workaround：构建一个包含 glibc 2.28 和对应 libstdc++ 的 sysroot，再通过 patchelf 让 VS Code Server 使用它。不过官方同时明确说，这属于技术性绕过方案，不是正式支持的使用场景。

评论区提到的项目

项目地址：

https://github.com/MikeWang000000/vscode-server-centos7

它的思路是把新版 VS Code Server 以及需要的运行库准备好，针对 RHEL/CentOS 7 做补丁，避免我们自己从头编译 glibc、研究 VS Code Server 的目录结构。

仓库目前提供了按 VS Code 版本发布的预编译包，Release 页面可以看到不同版本和架构的压缩包。例如 x86_64 服务器需要选择 x64 包，ARM 服务器则选择对应的 arm64 或 armhf 包。

Release 页面：

https://github.com/MikeWang000000/vscode-server-centos7/releases

安装方式

下面以 x86_64 服务器为例。

先确认服务器架构：

uname -m

如果输出是 x86_64，就下载 Release 中对应版本的：

vscode-server_<版本>_x64.tar.gz

把压缩包传到服务器后，执行：

mkdir -p ~/.vscode-server

tar xzf vscode-server_*.tar.gz \
  -C ~/.vscode-server \
  --strip-components 1

~/.vscode-server/code-latest --patch-now

这个项目 README 给出的核心步骤就是：

1. 下载 Release 压缩包
2. 解压到 ~/.vscode-server
3. 执行 code-latest --patch-now

执行完成后，再回到本地 VS Code，通过 Remote-SSH 连接服务器。

一个容易忽略的问题：版本要对应

VS Code Remote-SSH 连接时，客户端版本和远端 VS Code Server 版本是对应的。

本地 VS Code 升级以后，远端需要的 Server commit 也可能发生变化。如果下载的补丁包版本不匹配，可能会出现：

• 客户端仍然尝试下载自己的 Server
• 远程端已有文件没有被正确使用
• 连接后版本检查失败
• Server 启动后马上退出

所以不要只下载一个“看起来比较新”的包。最好先确认本地 VS Code 的版本，再到项目 Release 页面找对应版本。

本地可以通过 VS Code 的“关于”页面查看版本。也可以在命令行执行：

code --version

如果本地版本是 1.133.0，远端就优先选择项目中对应的 vscode-server_1.133.0_x64.tar.gz。

项目的 Release 通常会随着 VS Code 新版本更新，安装前最好重新看一下最新列表，不要长期保存一个旧压缩包反复使用。

如果想自己构建

不想使用预编译包，也可以从源码构建。项目 README 给出的流程大致是：

sudo scripts/yum-install.sh
scripts/download-deps.sh
make

不同架构可以通过 ARCH 指定：

make ARCH=x64
make ARCH=arm64
make ARCH=armhf

不过这个过程并不轻量。它涉及 glibc、GCC 工具链等内容，完整构建可能需要比较长时间，也需要准备足够的磁盘空间和编译依赖。

如果只是为了让一台旧服务器重新支持 Remote-SSH，优先使用 Release 中的预编译包更实际。自己构建更适合需要审查构建过程、定制架构，或者现成包无法满足需求的情况。

官方方案和这个项目的关系

官方文档给出的方案是：

1. 使用 Crosstool-NG 构建一个满足要求的 sysroot
2. 在远端安装 sysroot 和 patchelf
3. 设置以下环境变量

export VSCODE_SERVER_CUSTOM_GLIBC_LINKER=/path/to/sysroot/lib/ld-linux-x86-64.so.2
export VSCODE_SERVER_CUSTOM_GLIBC_PATH=/path/to/sysroot/lib
export VSCODE_SERVER_PATCHELF_PATH=/path/to/patchelf

然后由 VS Code Server 安装过程使用 patchelf 修改相关 ELF 文件，让它们找到新的动态链接器和运行库。

官方 FAQ 还特别提到，patchelf 0.17.x 已知可能导致 Remote Server 段错误，建议使用 0.18.x 或更高版本。

vscode-server-centos7 可以理解为把这套兼容思路进一步封装了：它提供构建好的 Server 包，并提供 --patch-now 入口，减少手工准备 sysroot 和修改文件的工作量。

我会怎么选

如果服务器可以升级系统，还是优先迁移到 CentOS 8/Stream、Rocky Linux、AlmaLinux 或其他仍在维护的发行版。这样解决的是根本问题，也不会一直被旧版 glibc、旧版内核和软件仓库拖着走。

如果服务器暂时不能动，比如：

• 设备属于实验室或客户，不能随便重装
• 运行着依赖 CentOS 7 的旧软件
• 需要保留当前驱动、CUDA 或硬件环境
• 迁移窗口还没有安排

那可以把这个项目当作过渡方案。它的价值主要是把影响范围控制在 VS Code Server，不去碰系统 glibc。

但要明确一点：

这只是解决 VS Code Server 的运行兼容性，不等于 CentOS 7 重新获得了安全更新，也不代表所有新版软件都能继续运行。

需要注意的几个坑

1. 不要覆盖系统库

不要把自己编译的 glibc 直接复制到 /lib64，也不要为了让 VS Code 能启动而修改系统默认动态链接器。

2. 先确认架构

x64、arm64、armhf 不是一回事。下载错误架构的包，解压成功也无法运行。

uname -m
file ~/.vscode-server/code-latest

3. 版本不匹配时先看客户端版本

不要看到远端有 ~/.vscode-server 就认为一定会被使用。VS Code Server 的版本和客户端 commit 需要对应。

4. 给目录留出空间

VS Code Server、运行库和扩展都会占用用户目录空间。空间不足时，安装过程也可能表现得像连接失败。

df -h
du -sh ~/.vscode-server 2>/dev/null

5. 这是兼容方案，不是长期方案

CentOS 7 已经结束生命周期。即使 Remote-SSH 恢复了，系统本身的漏洞修复、软件仓库和其他依赖问题仍然存在。

结尾

这件事真正需要避免的不是“VS Code 连不上”本身，而是为了修 VS Code，顺手把系统 glibc 改坏。

能迁移系统就迁移系统。暂时不能迁移，就把新版运行库隔离到用户目录，使用对应版本的 vscode-server-centos7，或者按官方文档自己构建 sysroot。

先把影响范围控制住，再考虑后续迁移。