开发 Mac 端工具时，我怎样保留 Bitvise 的连接习惯
我在开发 DartShell 这款 Mac 端远程运维工具时，需要判断 Bitvise 式连接操作中哪些部分值得保留。我把范围收窄到三个实际任务：保存 SSH 主机、在同一连接中管理 SFTP 文件，以及通过 SSH 隧道访问内网服务。单独找一个终端并不难，麻烦集中在连接状态、认证信息和文件传输如何继续复用。
Bitvise SSH Client 是 Windows 上常见的 SSH 客户端。它把终端、SFTP 和端口转发放在同一个图形界面里。长期使用后，很多操作已经形成固定习惯：选择保存的主机登录，打开文件窗口上传发布包，再启动端口转发连接数据库。
在 Mac 端分别使用系统终端、独立文件客户端和隧道命令，也能完成这些任务，只是主机配置需要重复填写，连接断开后的恢复方式也各不相同。进入实现后，我重点处理的就是这三部分操作关系。
SSH 主机记录要保存哪些信息
我先处理的是 SSH 主机数据。最初只记录地址、端口和用户名，实际使用时很快遇到认证差异：有的服务器使用密码，有的依赖私钥，还有的需要经过跳板机。
因此，主机记录至少要让这些字段保持明确：
- 主机地址与 SSH 端口
- 用户名及认证类型
- 私钥等认证配置
- 连接所需的代理或跳板设置
- 便于检索的名称与分组信息
这里有一个容易忽略的细节：界面显示“已连接”，只能说明会话已经建立，不能代表依赖该会话的文件面板仍然可用。我检查 SSH 会话状态时，还会继续验证 SFTP 通道能否重新创建，避免终端恢复后文件区域停留在旧状态。
当主机数量增加后，搜索名称和分组的作用也会变得明显。临时输入几十次地址很容易留下重复记录，后续再找测试机、生产机或跳板机时，主机列表会越来越难用。保存记录时把环境含义写进名称，比只保存 IP 更容易核对。
SFTP 迁移的重点在断线与传输状态
Bitvise 用户通常习惯在 SSH 登录后直接打开 SFTP。为了保留这个操作方式，我让文件管理依附于当前 SSH 主机，上传时直接使用已经确认过的连接配置，不再创建一份独立站点。
这部分开发中，我遇到过一次很具体的问题：SSH 重连成功后，从 SFTP 面板拖入文件，界面已经接收到拖放事件，上传却没有开始。检查后发现，上传入口仍然持有断线前的会话对象。终端显示正常，文件传输使用的通道已经失效。
修复时，我把重连后的会话重新绑定到 SFTP 上传入口，并再次验证三个动作：
- 断开 SSH 后重新连接；
- 在文件面板中拖入本地文件；
- 检查传输列表是否刷新，以及任务能否进入执行状态。
文件传输也不能只覆盖“开始”和“完成”。并发上传、取消上传、下载分块写入失败，都要有独立状态。比如取消任务时，需要终止正在使用的传输对象；下载数据写入本地失败时，则要保留错误信息，不能让界面继续显示成功。
如果你从 Bitvise 切换到 Mac，建议实际测试一次大文件上传、主动取消和断线重连。能够浏览目录，只说明 SFTP 已经建立；传输状态能否正确恢复，还要通过这些操作确认。
端口转发需要验证目标地址
完成终端和文件传输后，我继续处理 SSH 本地端口转发。它常用于访问仅在远端网络开放的 MySQL、PostgreSQL、Redis 或内部 Web 服务。
本地转发可以理解为：应用连接 Mac 上的本地端口，SSH 客户端再把流量转发到远端主机和端口。例如数据库只允许服务器内网访问时，可以让数据库客户端连接127.0.0.1上的监听端口，再由 SSH 会话把请求送到目标数据库。
我在实现时重点检查四个值：本地监听地址、本地端口、远端主机和远端端口。隧道建立成功后，还需要真正发起一次目标连接。仅看到监听端口存在，无法证明远端地址可达，也无法排除数据库端口填写错误。
端口转发的底层实现也经历过取舍。我测试过由 SSH 客户端直接创建本地转发，也尝试过调用随应用提供的 OpenSSH。涉及代理命令时，我曾加入ProxyCommand配置，随后又撤回相关改动。原因是帮助文本和配置入口能够完成，并不代表不同代理命令在应用环境里都能稳定执行。没有完成足够验证的入口，保留后会给连接排错增加变量。
最终保留的三项连接操作
经过这些实现和重连测试，我放弃了按 Bitvise 界面逐项复制的做法，转而围绕实际任务保留对应入口：主机记录负责 SSH 认证，连接后的文件面板负责 SFTP，端口转发继续复用同一台 SSH 主机。
如果你平时只使用 SSH 命令行，系统终端已经足够。若日常操作还包括拖放上传、维护多台主机和连接内网数据库，把这些入口集中管理会更接近原来的使用习惯，也能减少重复维护认证配置。