Ruby Net::SSH中forward.remote_dynamic怎么用？实现动态端口转发详解

在通过Ruby操作SSH隧道的场景中，静态端口转发（把本地某个端口映射到远端的固定主机端口）大家用得比较多，但遇到目标地址不固定、需要按请求动态决定访问目标的场景，静态转发就不够用了。Net::SSH库的Net::SSH::Connection::Session#forward对象提供了remote_dynamic方法，它等价于OpenSSH命令行的ssh -R 1080动态转发，能在远程服务器上监听一个SOCKS代理端口，把远端发来的请求通过SSH连接回传到本地，再由本地网络发出。这篇文章围绕这个方法展开，讲清楚它的原理、用法和容易踩的坑。

remote_dynamic的原理与参数说明

先理解方向问题。Net::SSH的转发分本地转发（forward.local）和远程转发（forward.remote）两类，而remote_dynamic属于远程方向的动态转发。它的含义是：在远程服务器上打开一个监听端口，任何连到这个端口的程序都把它当作SOCKS4或SOCKS5代理使用，请求目标地址由SOCKS协议动态携带，SSH通道把请求带回本地机器，由本地机器代替发起真正的TCP连接。

方法签名非常简单：

ssh.forward.remote_dynamic(port)
# port：远程服务器上要监听的端口号
# 返回值是一个Channel，可用于后续取消转发

与静态的forward.remote(port, host, remote_port)相比，动态版本不需要预先指定目标host和port，灵活性全部交给SOCKS协议协商。这带来的典型收益是：远程服务器上的一批脚本只需要配置一个代理地址，就能访问任意只在本地网络可达的服务，比如公司内网的数据库、只对办公网段开放的内部API等。

需要注意版本要求，remote_dynamic是在Net::SSH 6.0左右才加入的能力，早期5.x版本只有本地动态转发（forward.local_dynamic）。如果你的环境还是旧版本，调用会抛出NoMethodError，升级gem即可：

gem install net-ssh --version ">= 6.0"

完整代码示例：建立动态转发并保持会话

下面给出一个可直接运行的完整示例。核心要点有两个：一是调用remote_dynamic开启转发，二是必须让SSH会话的事件循环跑起来，否则通道上的数据不会被处理，代理端口形同虚设。

require 'net/ssh'

Net::SSH.start('跳板服务器地址', 'deploy', keys: ['/home/user/.ssh/id_rsa']) do |ssh|
  # 在远程服务器的 1080 端口开启 SOCKS 代理
  channel = ssh.forward.remote_dynamic(1080)
  puts "远程服务器 localhost:1080 已开启 SOCKS 动态转发"

  # 打开通道时的回调，便于确认状态
  channel.on_open do |ch|
    puts "远程监听通道已建立"
  end

  # 让事件循环持续处理转发数据
  ssh.loop(0.5) do
    !ssh.closed?
  end
end

运行这个脚本后，在远程服务器上执行curl --socks5 localhost:1080 http://内网服务地址，请求就会经由SSH连接回到你本地机器，再由本地访问目标。整个过程对远程服务器透明，它只知道自己连上了一个本机代理。

事件循环这里有一个新手常见误区：ssh.loop如果写成ssh.loop { false }会立即退出，转发瞬间失效；而不加任何条件的ssh.loop则会永久阻塞，直到连接断开抛异常。上面示例里用!ssh.closed?做条件，并传入0.5秒的心跳间隔，是比较稳妥的写法。如果想在一个线程里维持隧道、主线程继续做别的事，可以把整个start块丢进独立线程：

tunnel_thread = Thread.new do
  Net::SSH.start('跳板服务器地址', 'deploy') do |ssh|
    ssh.forward.remote_dynamic(1080)
    ssh.loop(0.5) { !ssh.closed? }
  end
end

# 主线程可以继续执行其他任务
sleep 60
tunnel_thread.kill

常见问题排查与生命周期管理

第一个高频问题是权限报错。如果远程服务器上的sshd配置了AllowTcpForwarding no或者PermitOpen做了限制，动态转发会建立失败，通常表现为通道一打开就被服务端关闭，客户端侧可能只看到连接静默中断。排查时先用系统自带的ssh -v -R 1080 user@host命令验证，如果命令行也失败，就去检查服务器上/etc/ssh/sshd_config的转发相关配置。

第二个问题是端口冲突。远程服务器上如果1080端口已被占用（比如已经跑着一个SSH动态转发），再次监听会失败。由于SOCKS动态转发的监听默认绑定在远端的localhost上，可以先用ss -tlnp | grep 1080确认占用情况，必要时换一个端口。此外，因为绑定在localhost，远程服务器上的其他机器无法直接使用这个代理，如果确实需要开放给远端局域网使用，需要在sshd配置GatewayPorts的前提下另行处理。

第三是取消转发与资源清理。返回的channel对象配合ssh.forward.cancel_remote可以在运行中关闭动态转发（部分版本支持按端口取消），或者简单粗暴地关闭整个SSH会话。建议在脚本里用ensure块保证异常退出时会话被正确关闭，避免远端残留半开连接：

ssh = Net::SSH.start('跳板服务器地址', 'deploy')
begin
  ssh.forward.remote_dynamic(1080)
  ssh.loop(0.5) { !ssh.closed? }
ensure
  ssh.close unless ssh.closed?
end

最后提一点适用边界：remote_dynamic目前支持SOCKS4/SOCKS5的TCP转发，不支持UDP，也不提供鉴权能力，适合内网工具链和自动化脚本使用，不适合直接暴露到不受信任的网络环境。把它理解为一条可编程的、由Ruby代码掌控生命周期的反向SOCKS隧道，就能在批量运维、内网穿透工具开发等场景里发挥出远超命令行的灵活性。

Ruby Net::SSHremote_dynamic动态端口转发修改时间：2026-09-05 01:08:34