文章

使用Linux远程开发(二)

原来的配置好像有点不管用了...

使用Linux远程开发(二)

前一则见:第一次使用Linux远程开发

最近又有需要远程服务器办公的任务,但是这次是在校外,原来的配置好像有点不管用了…

本篇记录下相较于上一次Linux开发新增的内容。

Xshell和Xftp

原先的旧办法会连续报试图写入的管道不存在,于是决定转向传统派办法,问了问组长,组长推荐了Xshell。

Xshell和Xftp的下载链接,对个人和学校用户免费,功能完全够用了。

Xshell是一款支持多协议的终端模拟器,专注于远程Linux主机的命令行运维;Xftp则是高性能的图形化文件传输客户端,通过类Windows资源管理器界面实现本地与服务器间文件的直观同步。两者组合强调运维稳定性与轻量化资源占用,在弱网环境下表现更稳健,通过独立窗口操作有效避免了集成开发环境对系统级管理任务的干扰。

相较于VSCode+SSH依赖远程服务端进程实现“挂载式”实时编辑的闭环,Xshell+Xftp的开发链路遵循“本地编辑-触发上传-远程生效”逻辑,在代码更改上存在操作延迟。VSCode方案能提供等同于本地的自动保存、语法检查与远程调试体验,而Xshell+Xftp组合则侧重于手动调度文件,难以实现跨文件跳转与实时插件交互,在代码开发效率上确实稍逊一筹。

另外还有一点值得一提,Xshell通过“会话属性”中的用户身份验证模块,支持永久保存SSH登录凭据(包括用户名、密码及私钥密码),实现双击即连,无需重复输入。相较于VSCode+SSH,虽然也可通过配置本地SSH Config文件并利用ssh-agent或SSH公钥认证(Public Key Authentication)实现免密登录,但在多服务器管理界面上,Xshell提供的图形化会话列表、文件夹分类管理以及主密码(Master Password)加密保护功能,在处理大量不同凭据的运维场景下比VSCode更加直观且便于维护。简单来说就是可以省去每次登陆都要输密码的麻烦,在自己的设备上开发,还是蛮省心的。

本地代理远程转发方案

在开发项目时需连接Hugging Face下载模型,因服务器通常无法直连hf且本地缓存配置繁琐,可采用SSH远程端口转发方案。

方案

该方案通过Windows设备为Linux服务器提供代理中转,具体步骤如下:

  1. 使用OpenVPN或其他VPN工具打通Windows与Linux之间的网络连接。
  2. 在本地Windows运行Clash等代理软件,监听7890端口(一般为默认设置),并确保开启“允许局域网连接”(Allow LAN)。
  3. 配置本地SSH配置文件(~/.ssh/config):
    1
    2
    3
    4
    
    Host my_server
      Hostname <server_ip>
      Port <ssh_port>
      User <username>
    
  4. 建立远程端口转发隧道,在Windows终端执行:ssh -v -NR 7890:localhost:7890 <username>@<hostname>。注:此指令将服务器侧的7890端口流量经由SSH隧道转发至Windows本地的7890端口。 注:此指令将服务器侧的 7890 端口流量经由 SSH 隧道转发至 Windows 本地的 7890 端口。
  5. 在服务器侧执行以下指令,将当前终端会话的系统环境变量指向SSH隧道映射的本地端口,使该Shell及其子进程的网络请求经由隧道转发至 Windows 侧代理软件: export http_proxy=http://127.0.0.1:7890 https_proxy=http://127.0.0.1:7890 若需避免重复输入,可执行vim ~/.bashrc将上述指令添加至末尾,实现代理配置的持久化,确保每次登录交互式Bash时自动启用代理环境。
  6. 验证验证代理是否生效: curl -I https://huggingface.co
  7. 针对特定工具的配置:
    • Conda:使用 conda config --show proxy_servers 查看配置。若需手动指定,执行: conda config --set proxy_servers.http http://127.0.0.1:7890 conda config --set proxy_servers.https http://127.0.0.1:7890
    • Git:执行以下指令设置全局代理: git config --global http.proxy http://127.0.0.1:7890 git config --global https.proxy http://127.0.0.1:7890
    • V2ray: 与 Clash 主要提供 HTTP 代理不同,V2Ray 默认通常同时开启 SOCKS5(常用于浏览器,端口默认 10808)和 HTTP(常用于命令行,端口默认 10809)两种入站协议。在配置远程转发时,需先在本地 V2Ray 客户端确认具体的 HTTP 监听端口,随后在 SSH 隧道命令中将该特定端口映射至服务器(如 ssh -NR 10809:localhost:10809 ...);最关键的区别在于环境变量赋值,若使用 SOCKS5 端口,http_proxyhttps_proxy 的前缀必须改为 socks5://(例如 export https_proxy=socks5://127.0.0.1:10808),否则 Git 或 Pip 等工具会因尝试进行 HTTP 握手而连接失败,而若使用 HTTP 端口则保持 http:// 前缀不变。

额外注意事项:

  1. 协议前缀限制https_proxy的值不应错误输入为https://127.0.0.1:7890。原因是代理软件(如Clash)提供的HTTP代理服务本身是非加密的,若前缀写为https,客户端会尝试与代理端口进行SSL握手,导致握手失败并中断连接。
  2. 权限报错:若Windows侧出现Bad owner or permissions on C:\\Users\[User]/.ssh/config错误(发生在第4步),需进入该文件属性,在“安全-高级”中禁用权限继承,并将文件所有者更改为当前登录用户。有汇报见于Issue
本文由作者按照 CC BY 4.0 进行授权