一个很常见的场景你人坐在 Windows 电脑前面SSH 里连着一台远端 Linux 服务器正在跑某个耗时任务。中途网络闪断SSH 直接挂掉任务虽然还在服务器上跑但你失去连接以后根本看不到输出只能重新登录进去再查日志。更麻烦的是你专门为了本地开发或查询数据库建立的隧道比如 3389、3306 这类端口转发一旦连接断掉就彻底失效应用连接不到服务器就只能报错。Autossh 解决的正是这个问题它像一个看门狗时刻盯着 SSH 进程发现连接断了自动重新拉起一个新的 SSH隧道也会跟着重建。这篇东西我主要讲 Windows 上怎么把 Autossh 跑起来怎么把它装成系统服务怎么让它开机自启。内容是我在维护远程服务器和本地开发环境的过程中总结出来的实操记录适合所有需要在 Windows 下长期使用 SSH 连接的运维和开发同学。1. Autossh 是什么为什么 Windows 用户需要它1.1 核心机制Autossh 到底在做什么Autossh 本质上是一个 SSH 会话的守护包装器。它不是在某个虚拟层里“加强” SSH而是通过一个非常简单但可靠的逻辑来工作启动一个完整的 SSH 子进程用一个独立的监控通道持续检测该 SSH 是否仍然存活如果检测到 SSH 进程异常退出立刻启动一个新的 SSH 进程并重新建立端口转发如果只是短暂抖动它还能自动等待一段时间再重试避免疯狂重连。这个机制的通俗理解是SSH 本身只负责一次连接Autossh 负责让这次连接“永远活着”。在 Linux 上Autossh 是老牌工具了几乎所有发行版都有现成包。而 Windows 上就比较折腾官方不提供原生安装包这也是我写这篇记录的直接原因。1.2 Windows 场景里的真实痛点我见过不少 Windows 用户维护远程服务器的方式是打开 Windows Terminal 或者 PuTTY手动敲 ssh 命令连接断开就再敲一次。单次连接无所谓但有两种情况特别难受长期保持的隧道把远端服务器的 MySQL 端口、Redis 端口或某个内部管理后台端口映射到 Windows 本地供 IDE、数据库客户端访问。隧道断掉客户端先报错你再去手动重建隧道中间业务已经受影响。远程执行任务远程跑打包、备份、数据迁移等耗时操作SSH 断开后重连之前的终端状态已经丢失想要重新查看日志还得手动找 session。尤其当你用跳板机做中转或者公司网络半夜会自动回收空闲连接时这种断连几乎无法避免。Autossh 的价值就是在你不过度干预的情况下自动把连接和隧道恢复让本地的数据库工具连着的端口“只是卡顿几秒然后恢复”。1.3 合规应用场景与预期我日常把它用在三类地方都属于很常规的运维和开发需求远程维护多台 Linux 服务器通过 Windows 上的 Autossh 保持一个稳定的跳板会话。本地开发环境连接内部资源比如本地 Spring Boot 服务需要连远端办公网的MySQL而办公网只允许 SSH 访问。临时端口转发需要把一个远端服务端口映射到本地来抓包、调试、定位问题。很多人会在搜索 Autossh 时联想到“内网穿透”四字但请注意任何工具都只能解决合法的网络管理问题。如果你的目标仅仅是保持自己有权访问的服务器的连接不中断Autossh 非常合适如果试图绕过网络权限边界那你应该回头重新评估自己的访问策略。2. 安装方式选型Cygwin、WSL2 还是 MSYS2在 Windows 上跑 Autossh没有“唯一正确”的方案只有“适合你的场景”的方案。我不建议盲目照搬网上某一种教程先花几分钟把三条路线搞清楚后面能少踩很多坑。选型安装复杂度服务化难度依赖环境推荐场景Cygwin中等容易独立的 Unix 模拟层需要注册成 Windows 服务老机器或不想装 WSL 的人WSL2中等较难Windows Subsystem for Linux已经在重度使用 WSL以发行版命令为主的人MSYS2/Git Bash较高较复杂MinGW 工具链不推荐除非你追求完全便携2.1 Cygwin最“原生”的 Windows 方案Cygwin 在 Windows 上提供了一套完整的 Unix 模拟环境Autossh 可以直接以“Windows 进程”的方式运行。这意味着后面用 NSSM 注册成 Windows 服务时非常方便服务管理器直接操作的是一个 .exe 进程而不是整个 WSL 发行版。我在实际项目里最推荐的就是这条路。Cygwin 的缺点也有它的文件路径、环境变量和原生 Windows 有一些差别比如路径分隔符要用/cygdrive/c/...这样的格式还有系统服务的登录账户是 SYSTEM密钥文件路径必须显式指定否则它找不到。2.2 WSL2适合开发者的清静环境WSL2 其实更适合喜欢“把所有运维命令放在 Linux 子系统里跑”的开发者。你只需要在 Ubuntu 里apt install autossh然后像在 Linux 服务器上一样配置.ssh/config使用体验确实连贯。但它的麻烦在于WSL2 本身不是为“常驻后台无感服务”设计的。你打开一个终端窗口启动 autossh窗口关掉WSL 实例没有自动退出时进程可能还在但网络地址、端口转发等机制可能因 WSL 实例的 NAT 模式而失效。要把它做成开机自启、隐身运行的服务还需要额外的wsl.exe调用和 Windows 计划任务配合比 Cygwin 绕。2.3 MSYS2 / Git Bash看起来近实际上坑多Git Bash 在 Windows 用户里普及度很高因为它随 Git for Windows 一起安装。很多人会先入为主地去 Git Bash 里找 autossh结果发现没有现成包。MSYS2 的包管理器有 autossh但 MSYS2 的环境完整性和 Cygwin 比还是偏“精简”而且如果你已经装了 Git for Windows再装一套 MSYS2环境变量和动态库容易打架。我的结论强烈建议准备长期使用的人直接选 Cygwin想体验 Linux 原生环境的选 WSL2。Git Bash 那条路除非你只是临时跑一下否则不推荐。3. 实战安装两种主流方案的完整步骤3.1 方案一Cygwin 安装 Autossh推荐3.1.1 下载并安装 Cygwin 基础环境去 Cygwin 官网下载setup-x86_64.exe。安装时注意几个关键选择安装目录我建议用C:\tools\cygwin64避免路径里有空格后面注册服务时少很多麻烦选择软件源时默认的主站可能很慢换用国内的镜像源比如清华开源镜像站https://mirrors.tuna.tsinghua.edu.cn/cygwin/在包选择界面搜索autossh它位于 Net 分类下。同样再搜索openssh确保 OpenSSH 客户端也装上。Autossh 本身只是一个包装器底层必须依赖 SSH 客户端。选择完成后点击下一步等待安装完成。这一步耗时和网络质量关系很大耐心等就行。3.1.2 配置 Windows 系统环境变量Cygwin 装好后它的命令默认只能在 Cygwin Terminal 里执行。为了让autossh命令可以被原生的 cmd、PowerShell、NSSM 服务管理器直接调用我需要把 Cygwin 的 bin 目录加入 Windows 的 PATH。操作路径右键“此电脑” - 属性 - 高级系统设置 - 环境变量 - 在“系统变量”里找到 Path编辑新增C:\tools\cygwin64\bin。然后打开一个新的 cmd 窗口执行验证where autossh autossh --version如果你能看到类似版本号输出说明 Cygwin 环境下的 autossh 已经可以被 Windows 系统直接调用了。这个步骤很多人会忽略如果这里不配置后面注册服务时 NSSM 会一直提示找不到程序。3.1.3 安装 SSHD 客户端依赖Autossh 运行起来后实际上是在执行类似ssh的命令。在 Cygwin 环境里它默认调用的是 Cygwin 自己编译的 OpenSSH。如果你在安装过程中忘了勾选openssh启动时会报ssh: command not found。我一般会顺手把服务器端openssh-server也装上虽然本机作为客户端用不到服务端功能但 Cygwin 的某些依赖包是一起被拉进来的。这一步纯粹是为了避免依赖缺失造成的动态库错误。3.2 方案二WSL2 安装 Autossh备选3.2.1 启用 WSL 并安装 Ubuntu如果你选择 WSL2前提是你的 Windows 版本支持且已启用虚拟化。以管理员身份打开 PowerShell执行wsl --install安装完成后重启系统然后安装 Ubuntu 发行版。不管是从 Microsoft Store 里装还是用wsl --install -d Ubuntu本质都一样。装好后打开 Ubuntu 终端第一步建议换个 apt 源不然apt install autossh的速度可能令人崩溃。3.2.2 安装 autossh 并验证在 WSL 终端中执行sudo apt update sudo apt install autossh openssh-client autossh --version这个版本来源和 Cygwin 完全是两回事它直接使用 Ubuntu 软件源里编译好的二进制依赖关系相对干净。如果你已经熟悉 Linux 的 ssh 配置那么后续的免密登录、SSH config 都可以直接用这是 WSL2 的最大优势。但前面也说了WSL2 的进程是跑在虚拟机里的。如果你想让它作为后台服务自动启动需要在 Windows 的计划任务里设置一个开机任务执行wsl.exe -d Ubuntu -- /usr/bin/autossh -M 0 -N -L 3306:127.0.0.1:3306 user192.168.1.100问题在于wsl.exe启动是有窗口的而且 WSL 的虚拟网络地址不是固定不变的经常出现 Windows 宿主访问不到 WSL 内部监听端口的情况需要手动执行wsl --shutdown再重启。除非你有足够耐心做网络适配否则我建议把这条方案定位为“临时用用”。4. 配置 Autossh 实现 SSH 隧道自动重连4.1 先解决免密登录让 Autossh 全自动运行Autossh 最大的价值是“无人值守”所以第一步一定是配置 SSH 免密登录。否则你每次连接断了它虽然自动拉起 ssh但还要等你在终端里输密码这就不算真正的自动了。推荐用ed25519密钥对执行ssh-keygen -t ed25519 -C win-autosshyourname把公钥拷贝到远程服务器上ssh-copy-id -i ~/.ssh/id_ed25519.pub useryour-server如果没有ssh-copy-id命令就手动追加把~/.ssh/id_ed25519.pub的内容追加到远程服务器的~/.ssh/authorized_keys文件末尾然后确保远程目录和文件权限正确chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys这里要提醒一个 Windows 特有的坑如果你的 Windows 本身已经安装了原生 OpenSSH 客户端并且生成过密钥密钥默认存在C:\Users\你的用户名\.ssh\下而 Cygwin 环境下的ssh默认读取的是 Cygwin 内部用户目录通常是C:\tools\cygwin64\home\系统用户名\.ssh\。两边的密钥是不互通的。你必须在 Cygwin 终端里执行密钥生成或者把已有私钥复制到 Cygwin 对应的.ssh目录下。4.2 手动测试一条隧道确认基础命令正确在真正启动 Autossh 之前先用最朴素的 SSH 命令测试隧道是否工作。我这里用一个常见的例子将远程服务器的 MySQL 3306 端口映射到本地 3306。ssh -N -L 3306:127.0.0.1:3306 useryour-server -p 22如果这条命令能跑通本地就能通过127.0.0.1:3306访问远程 MySQL。确认没问题后把这条命令CtrlC断开接下来把它交给 Autossh。4.3 启动 Autossh 并理解关键参数Autossh 的命令格式和 ssh 非常像只是开头多了一些给 Autossh 自己用的参数autossh -M 20000 -N -L 3306:127.0.0.1:3306 -o ServerAliveInterval60 -o ServerAliveCountMax3 useryour-server -p 22参数解释-M 20000指定一个监控端口Autossh 会在这个端口上建立一个 TCP 测试通道用它来持续探测 SSH 连接的状态。-N不执行远程命令只做端口转发。-L 3306:127.0.0.1:3306本地端口到远程目标的映射含义和 ssh 一致。-o ServerAliveInterval60每 60 秒由 SSH 客户端向服务器发送一次保活探测包。这个参数非常重要因为很多网络设备会静默清理空闲连接没有保活包时服务器还在但连接已经断了Autossh 却完全不知道。-o ServerAliveCountMax3连续 3 次没有收到服务器响应才判定连接真的失联。经验之谈-M端口不能随意用已经被占用的端口否则 Autossh 无法建立监控通道会一直重启循环。而且在实际使用中-M检测的是两端 TCP 通断在复杂的防火墙环境里不一定可靠。我个人的习惯是把-M和ServerAliveInterval配合使用两者互为补充一个从应用层保活一个从链路层检测。4.4 把 Autossh 注册成 Windows 服务如果要让 AUTOSSH 开机自启并真正做到“无人值守”就需要把它做成 Windows 服务。这里我用的工具是 NSSMNon-Sucking Service Manager一个小型服务封装器比 sc.exe 好用得多配置也更直观。从 NSSM 官网下载对应版本的压缩包解压后把win64/nssm.exe放到C:\tools\nssm\nssm.exe然后以管理员身份打开 cmdC:\tools\nssm\nssm.exe install AutosshService此时会弹出图形化配置窗口。关键配置如下PathC:\tools\cygwin64\bin\autossh.exeStart directoryC:\tools\cygwin64\binArguments-M 20000 -N -L 3306:127.0.0.1:3306 -o ServerAliveInterval60 -o ServerAliveCountMax3 useryour-server -p 22然后切到“Log on”标签选择允许服务与桌面交互可以不勾选。重点是默认情况下服务会以 SYSTEM 账户运行而 SYSTEM 账户没有你当前用户目录下的 SSH 私钥权限。解决办法在 NSSM 的Environment标签里加两行USERPROFILEC:\Users\你的用户名 HOMEC:\Users\你的用户名或者在 Autossh 的 ssh 参数里直接用-i指定私钥绝对路径例如-i C:\tools\cygwin64\home\你的用户名\.ssh\id_ed25519。配置完成后回到 NSSM 主窗口点击“Install service”。然后在服务管理里或者命令行启动net start AutosshService启动后可以用ss -antl或者netstat -ano | findstr 3306检查本地端口是否已经进入监听状态。如果你本机已经有其他程序占用了 3306服务会起不来日志里会显示bind: Address already in use这时要么换本地端口比如-L 3307:127.0.0.1:3306要么停掉占用程序。5. 常见故障排查与经验分享5.1 循环重启端口占用和参数错误是最常见原因Autossh 的问题是它不会“安静地失败”。一旦启动失败它会按照你设定的重试间隔不断拉起新进程。如果第一次拉起的 SSH 已经占用了本地端口第二次启动时就会因为Address already in use反复失败。排查方法很简单get-process sshd, ssh, autossh如果看到一堆 ssh 进程先全部杀掉taskkill /F /IM ssh.exe /IM autossh.exe然后把本地端口改成一个没人用的端口比如-L 13306:127.0.0.1:3306在服务配置里改掉 Arguments重启服务。我在实际使用中就踩过这个坑本地 MySQL 的 3306 端口一直开着Autossh 每次尝试绑定都失败日志里全是bind: Address already in use折腾了半小时才定位。5.2 NSSM Cygwin 环境变量塌陷Cygwin 下的程序依赖/etc/passwd、HOME等环境变量而 Windows 服务启动时由 SCM 传给进程的环境变量很少。除了前面说的 USERPROFILE 问题还有一个坑是 Cygwin 程序的动态库搜索路径。如果你在 NSSM 里把 Start directory 设置错了或者系统里同时安装了多个版本的cygwin1.dll启动时可能出现“找不到 cygwin1.dll”的弹窗但服务管理器里没有界面你只能通过 NSSM 配置的输出日志看到错误。建议在 NSSM 的 I/O 标签页里指定一个日志文件比如C:\logs\autossh-service.log把 stdout 和 stderr 都写进去。排查时直接看日志比自己瞎试高效得多。5.3 WSL2 方案的固有烦恼WSL2 安装的 autossh 虽然没有 Cygwin 动态库的问题但 WSL2 本身的启动机制决定了它不是为“系统服务”设计的。WSL 的虚拟交换机网络拓扑在每次冷启动后可能不同如果你的 Windows 上还开启了防火墙Windows 宿主连接 WSL 内的端口转发时很容易不通。我的建议是WSL2 方案适合“人在电脑前需要一个 Linux 风格的后台任务”的场景但如果你想达到“开机就自动建立隧道并且持续稳定运行几周不碰它”的目标直接用 Cygwin NSSM 才是正路。5.4 连接依然会偶尔卡死正确理解 Autossh 的检测粒度Autossh 不是万能的。如果 SSH 进程本身一直活着但底层链路已经“假死”——比如网络设备缓冲异常TCP 窗口不再推进——Autossh 的监控探测也可能被卡住。这也是我强调要加ServerAliveInterval的原因。只有让 SSH 协议层主动发现失联才能触发 Autossh 的“重连”逻辑。另外连接正常的长时间运行中如果远程服务器重启或者 Docker 容器重启导致端口转发失效Autossh 往往不会立即感知因为 ssh 进程本身没退出。我处理这类问题的经验是在远程服务器上部署一个健康检查脚本定时探测本机被转发的端口一旦不通直接杀掉对应的 ssh 进程让 Autossh 因为ssh exited触发重连。5.5 多条隧道如何管理如果你需要同时保持多条隧道比如同时映射远程服务器的 MySQL、Redis 和某个内部管理后台可以给每一条隧道单独创建一个 Autossh 服务Autossh-MySQL、Autossh-Redis、Autossh-Admin。每个服务用不同的监控端口和本地端口互不干扰。这不是浪费资源而是让一个服务的故障不会拖垮其他隧道排查时也更清晰。最后说几句真心话Windows 上使用 Autossh 的教程网上不少但多数都停在“安装成功”这一步真正把服务化、开机自启、故障恢复串起来讲清楚的不多。我个人经过长期使用后最终固定的方案就是 Cygwin NSSM安装一次配置好密钥和 NSSM 后重启电脑都不用管隧道自己建好。唯一需要定期关心的是密钥是否被轮换、远程服务器 IP 是否变化。如果你也打算在 Windows 上长期使用 SSH 隧道我建议一开始就直接按这个组合落地别在 Msys2 和 WSL2 上反复横跳了省下的时间还不如多看两行日志。