When remote development is worth it
Three typical scenarios: ① code must stay on the intranet (compliance forbids syncing locally); ② heavy work needs remote compute (training, builds, large test suites) with the laptop only editing; ③ dependencies only run on Linux. Remote-SSH deploys a VSCode Server into ~/.vscode-server on the remote host — the UI renders locally while language servers and terminals execute remotely, so opening a huge repo barely touches local RAM.
# 安装:扩展市场搜索 "Remote - SSH"(ms-vscode-remote.remote-ssh)Three steps: host, passwordless, platform
① Put the server in ~/.ssh/config (alias + user + key) — Remote-SSH reads this file directly for host selection; ② verify passwordless access from a terminal first (`ssh alias`) with keys configured — this single step eliminates 90% of connection problems; ③ run Remote-SSH: Connect to Host from the command palette; the first connect auto-downloads the platform-matching vscode-server.
For bastion hosts one ProxyJump line in the config replaces manual double-hopping.
Host gpu-box
HostName 10.0.0.8
User dev
IdentityFile ~/.ssh/id_ed25519
ProxyJump bastion.corp.internal # 跳板机一行搞定Five steps when connection fails
① Can a bare terminal `ssh alias` connect? If not, fix the SSH layer first (permissions/keys/network) instead of retrying inside VSCode; ② is the remote disk full? vscode-server writes hundreds of MB into ~/.vscode-server, and a full disk hangs the connect at "Setting up SSH Host"; ③ corrupted ~/.vscode-server (interrupted upgrade, wrong arch): delete the directory and reconnect to reinstall; ④ remote glibc too old: very old distros cannot run new server builds — pin an older VSCode or upgrade the OS; ⑤ port forwarding failures: local proxy/VPN conflicts or a firewall blocking the channel.
df -h ~ # 远端磁盘是否写满
rm -rf ~/.vscode-server # 损坏时重置(重连自动重装)Tuning the experience: extensions, ports and git
Extensions split into local and remote sides: language ones (Python/ESLint) must be "Installed in SSH: xxx" on the remote; themes and icons stay local. When a dev server runs on a remote port, forward it via the Ports panel — browsing localhost:3000 then hits the remote service, the core convenience for debugging.
Git runs on the remote, so push auth uses remote credentials (SSH keys or a credential helper there), independent of your local GitHub login — misplacing this is the number-one cause of "why does push always 403".
# 命令面板常用:
Remote-SSH: Connect to Host
Forward Port... # 远端端口映射到本地
Install in SSH: <host> # 扩展装到远端Choosing between this and bare SSH + vim
Remote-SSH suits code-centric daily work: full IDE powers (navigation, refactoring, debugger) plus remote compute. When the server has only a few hundred MB to spare, or you are firefighting two config lines, a bare ssh + vim is lighter. They do not conflict: if vscode-server cramps the disk, deleting it rolls back cleanly with no residue.
du -sh ~/.vscode-server # 看远端 server 占用
rm -rf ~/.vscode-server # 完全卸载(下次重连会重新下载)Wrap-up checklist
Alias in config → verify passwordless in a terminal → Connect to Host → install language extensions remotely → forward ports for debugging → configure git credentials on the remote. After these six steps the remote experience is nearly local; when connection issues arise, first check the bare SSH layer, then the vscode-server layer.
ssh 别名 && code . # 免密就绪后,一条命令进入远程开发