remote-ssh连通后环境变量、终端、插件失效是常态,主因是启动非登录非交互式shell导致~/.bashrc不加载、私钥权限非600、ssh_config中identityfile未用绝对路径、缺少tar/gzip或glibc版本过低等。

能连上不代表能开发——Remote-SSH 连通后环境变量、终端、插件全失效,是常态,不是异常。
Permission denied (publickey) 但终端能 ssh 成功
VSCode Remote-SSH 不继承终端的 SSH 环境,哪怕你用 ssh-agent 或 pageant 存了密钥,它也看不到。
- 私钥文件权限必须是
600(chmod 600 ~/.ssh/id_rsa),VSCode 会严格校验,宽松权限直接拒绝 -
~/.ssh/config中的IdentityFile必须写绝对路径,~/开头的会被解析失败,换成/home/yourname/.ssh/id_rsa - 若依赖
ssh-agent,在~/.ssh/config加ForwardAgent yes,并确认 agent 已加载密钥(ssh-add -l可查) - Windows 用户建议启用系统级 OpenSSH Authentication Agent 服务,而非仅靠 Git Bash 的 agent
连接成功但终端打不开 / 命令找不到(node、git、conda 全报 command not found)
Remote-SSH 启动的是非登录、非交互式 shell,~/.bashrc 和 ~/.zshrc 默认不加载。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
- 检查远程服务器上该用户的默认 shell:
grep ^$USER /etc/passwd,确保不是/bin/false或/usr/sbin/nologin - 在
~/.bash_profile或~/.profile末尾加一行:[[ -f ~/.bashrc ]] && source ~/.bashrc - 如果用 zsh,确保
~/.zprofile中有source ~/.zshrc;VSCode 默认走$SHELL,但只读一次 login shell 配置 - 别在
~/.bashrc开头加echo、clear或阻塞型命令——Failed to fetch remote environment很可能就因这行输出
卡在 “Setting up SSH Host” 或 “Installing VS Code Server”
这不是网络慢,而是远程服务器缺基础依赖或初始化失败。
- 手动登录服务器,运行:
bash -ilc 'echo OK'(-i表示交互,-l表示登录),无输出或报错说明 shell 配置有语法错误 - 确认远程已安装
tar和gzip:VSCode Server 上传解压强依赖这两个命令,CentOS 最小化安装常缺gzip - 检查 glibc 版本:
ldd --version,要求 ≥ 2.17;老旧系统(如 CentOS 6)或 Alpine Linux 无法运行 vscode-server - 确认用户主目录剩余空间 ≥ 200MB:
df -h ~,vscode-server 解压后约 150MB,临时文件另计
文件保存慢、Git 操作卡顿、终端响应延迟高
这不是 VSCode 性能问题,而是 Remote-SSH 的工作模式决定的:所有操作都在远程执行,本地只渲染 UI。
- Git 提交、diff、blame 全部走远程
git命令,网络延迟 + 远程磁盘 I/O 是瓶颈,不是插件问题 - 文件保存实际是通过 SSH SFTP 协议同步,大文件或大量小文件会明显变慢
- 避免在远程打开超大日志文件或 node_modules 目录;可在 VSCode 设置中禁用文件监视:
"files.watcherExclude": {"**/node_modules/**": true} - 若服务器启用了 SELinux,临时设为 permissive 测试:
sudo setenforce 0,排除策略拦截干扰
最易被忽略的一点:VSCode Remote-SSH 不是“远程桌面”,它不转发 X11、不共享剪贴板、不继承终端历史。一切行为都受限于远程用户的 shell 权限、PATH、可用命令和初始化逻辑——连得上只是第一步,能干活才是关键。










