SSH

背景

一台 Arch Linux KDE 桌面环境中使用 Tabby 作为日常终端和 SSH 客户端。系统中维护了多个 SSH 连接配置，其中包括两台通过公网入口和端口转发访问的树莓派。

某次调整树莓派系统后，Tabby 连接这两台树莓派时同时报错：

WrongServerSig

奇怪的是，其他服务器在 Tabby 中都能正常连接，只有这两台树莓派出问题。

一开始很容易怀疑是 SSH 配置、host key、known_hosts、端口映射或树莓派系统本身的问题。但最终排查结果证明：问题并不在服务器端，也不在 .ssh/config，而是 Tabby 某个版本的内置 SSH 实现存在兼容性问题。

初始现象

Tabby 中通过 SSH profile 连接树莓派时失败，界面显示类似：

SSH Connecting to Raspberry-XXX (.ssh/config)
WrongServerSig

但直接在系统终端中执行 OpenSSH 命令可以正常连接：

ssh root@<PUBLIC_DOMAIN> -p <PORT_A>
ssh root@<PUBLIC_DOMAIN> -p <PORT_B>

进入系统后，两个远程系统都正常响应，说明：

  • 公网域名解析正常；
  • 端口转发正常；
  • 远程 sshd 正常；
  • root 登录权限正常；
  • 网络链路没有问题。

更关键的是，在 Tabby 中打开一个普通本地 shell，再手动执行系统 ssh 命令，也可以正常连接两台树莓派。

这说明问题不是 Tabby 作为终端模拟器的问题，而是 Tabby 自己的 SSH profile / 内置 SSH 客户端存在问题。

检查 .ssh/config

相关 SSH 配置大致如下：

Host Raspberry-A
    HostName <PUBLIC_DOMAIN>
    Port <PORT_A>
    User root

Host Raspberry-B
    HostName <PUBLIC_DOMAIN>
    Port <PORT_B>
    User root

OpenSSH 能正确解析配置：

ssh -G Raspberry-A | grep -E '^(hostname|port|user) '
ssh -G Raspberry-B | grep -E '^(hostname|port|user) '

输出中的 hostname、port、user 都正确。

因此，.ssh/config 的基本格式没有问题，端口也没有写反。

检查服务器 host key

接着使用 ssh-keyscan 检查两台树莓派实际暴露的 SSH host key：

ssh-keyscan -T 5 -p <PORT_A> -t rsa,ecdsa,ed25519 <PUBLIC_DOMAIN> > /tmp/rpi-a.keys
ssh-keyscan -T 5 -p <PORT_B> -t rsa,ecdsa,ed25519 <PUBLIC_DOMAIN> > /tmp/rpi-b.keys

ssh-keygen -lf /tmp/rpi-a.keys -E sha256
ssh-keygen -lf /tmp/rpi-b.keys -E sha256

结果显示，两台树莓派都提供了：

8192-bit RSA host key
256-bit ED25519 host key

而且系统 OpenSSH 可以正常使用这些 key 完成连接。

这一步说明：服务器端 host key 本身不是坏的。

检查 Tabby 自己的配置缓存

Tabby 的用户配置目录位于：

~/.config/tabby

其中 config.yaml 内存在 Tabby 自己维护的 SSH knownHosts 记录。里面确实可以看到旧的 host key / fingerprint 记录。

一开始推测 Tabby 可能拿旧记录做校验，所以尝试编辑 config.yaml 中相关 knownHosts 项。但实际验证后发现：

  • 直接编辑 config.yaml 并不能解决 WrongServerSig；
  • 删除过多记录还可能影响其他 SSH profile；
  • Tabby 除了 config.yaml 外，还会在 Local Storage / LevelDB 等位置保存额外状态；
  • 因此不能把问题简单归结为 config.yaml 中某一段缓存。

这一阶段得到的结论是：Tabby 的缓存可能参与了问题，但不是唯一因素，也不适合通过粗暴删除配置来解决。

引入 AI 代理做批量排查

由于 Tabby 的配置目录、缓存文件、Local Storage、profile cache、日志文件较多，人工逐项确认成本较高，于是让本地 AI 代理执行只读排查。

排查要求包括：

  • 不删除整个 ~/.config/tabby；
  • 不修改服务器 sshd 配置；
  • 不 reload / restart sshd；
  • 不改 .ssh/config；
  • 只搜索 Tabby 相关缓存、日志、profile；
  • 确认 Tabby 实际安装方式、版本、配置目录；
  • 搜索 WrongServerSig、host key、fingerprint、profile、端口等关键字；
  • 判断 Tabby 是否真的使用系统 OpenSSH，还是使用内置 SSH 引擎。

AI 代理返回的关键结果是：

  • 当前安装包为 tabby-bin 1.0.234-1；
  • 可执行文件由 /usr/bin/tabby 启动，实际程序位于 /opt/Tabby/tabby；
  • Tabby 使用自己的内置 SSH 流程，不是直接调用系统 ssh；
  • ~/.config/tabby/config.yaml 中确实有 Tabby 自己的 knownHosts；
  • Local Storage / LevelDB 中也有 SSH profile / algorithm 相关缓存；
  • 系统 OpenSSH 的 known_hosts 正常；
  • 问题集中在 Tabby 自己的 SSH 实现或缓存状态。

进一步确认：可能是软件版本问题

随后查询相关问题，发现 Tabby 的 GitHub 讨论中已有多个类似案例：

  • 错误同样是 WrongServerSig；
  • 系统 OpenSSH 可以连接；
  • Tabby 自己连接失败；
  • 有用户反馈降级到较早版本后恢复；
  • 相关问题集中在 Tabby 某些新版本的 SSH 后端变化之后。

本机检查安装包：

pacman -Q | grep -Ei 'tabby'

pacman -Qo /usr/bin/tabby
pacman -Qo /opt/Tabby/tabby

pacman -Qi tabby-bin

输出确认当前使用的是：

tabby-bin 1.0.234-1

而不是 AUR 上另一个源码构建包 tabby。

这里容易产生误解：AUR 中存在多个相近包名，例如：

tabby
tabby-bin
tabby-electron-bin

系统中运行的 tabby 命令并不代表安装包一定叫 tabby。当前实际安装的是 tabby-bin，它提供了 tabby 命令。

最终修复

最终采取的修复路线是：

  1. 卸载当前有问题的 tabby-bin 1.0.234-1；
  2. 改为安装 AUR 中的 tabby 源码构建包；
  3. 不删除用户配置；
  4. 不修改 .ssh/config；
  5. 不修改树莓派 sshd；
  6. 安装完成后重新用 Tabby 的 SSH profile 测试两台树莓派。

处理前先备份配置：

pkill -x tabby 2>/dev/null || true

TS=$(date +%F-%H%M%S)
mkdir -p ~/workspace/tabby-backup-$TS
cp -a ~/.config/tabby ~/workspace/tabby-backup-$TS/
cp -a ~/.ssh/config ~/workspace/tabby-backup-$TS/ssh_config.bak

卸载旧包：

sudo pacman -R tabby-bin

随后安装 AUR 的 tabby 源码包。

安装后再次测试 Tabby SSH profile，两台树莓派均恢复正常连接。

最终结论

这次故障的根因不是：

  • .ssh/config 配置错误；
  • 端口写错；
  • 公网入口异常；
  • FRP 转发异常；
  • 树莓派 sshd 异常；
  • 系统 OpenSSH known_hosts 异常；
  • 用户误操作。

真正的问题是：

tabby-bin 1.0.234-1 的 Tabby 内置 SSH 实现存在兼容性问题，导致连接特定 SSH host key 组合的服务器时报 WrongServerSig。

切换到 AUR 的 tabby 源码构建包后，问题解决。

经验总结

1. 系统 OpenSSH 能连，Tabby SSH profile 不能连时，不要立刻改服务器

如果以下命令正常：

ssh root@<PUBLIC_DOMAIN> -p <PORT>

并且在 Tabby 本地 shell 中执行同样命令也正常，那么服务器端基本可以排除。

这时问题更可能在：

  • Tabby 内置 SSH 引擎；
  • Tabby profile；
  • Tabby knownHosts；
  • Tabby Local Storage；
  • Tabby 当前版本。

2. Tabby 不等于系统 ssh

Tabby 既可以作为普通终端运行系统 ssh，也可以使用自己的 SSH profile。

这两条路径不同：

Tabby 本地 shell + 系统 ssh      → 使用 OpenSSH
Tabby SSH profile               → 使用 Tabby 内置 SSH 实现

因此，“Tabby 里系统 ssh 能连”并不等于“Tabby 的 SSH profile 一定能连”。

3. AUR 包名要看清

tabby 命令不等于安装包一定叫 tabby。

可以用下面命令确认实际包名：

pacman -Q | grep -Ei 'tabby'
pacman -Qo /usr/bin/tabby
pacman -Qo /opt/Tabby/tabby 2>/dev/null

本次实际安装的是：

tabby-bin

而不是：

tabby

4. 不要轻易清空 Tabby 配置目录

~/.config/tabby 中保存了大量设置，包括：

  • SSH profiles；
  • knownHosts；
  • UI 设置；
  • 插件状态；
  • Local Storage；
  • profile cache。

遇到 SSH 问题时，不应直接删除整个目录。更稳妥的做法是：

  1. 先备份；
  2. 只读排查；
  3. 确认版本问题后优先换版本；
  4. 最后才考虑最小范围清理缓存。

5. 出现 WrongServerSig 时应优先怀疑客户端版本

WrongServerSig 看起来像服务器签名校验失败，但并不一定表示服务器有问题。

如果系统 OpenSSH 能正常连接，而 Tabby 失败，就应优先检查：

pacman -Q | grep -Ei 'tabby'

并搜索当前版本是否存在相关 issue。

建议记录

本次故障可以记录为：

某日期：Tabby SSH profile 连接两台树莓派时报 WrongServerSig。系统 OpenSSH 直连正常，Tabby 本地 shell 中执行 ssh 正常，公网入口、端口转发、树莓派 sshd、.ssh/config 均正常。排查后确认问题出在 tabby-bin 1.0.234-1 的内置 SSH 实现。卸载 tabby-bin 并改用 AUR tabby 源码构建包后，连接恢复正常。后续遇到类似问题，应优先检查 Tabby 版本，不要优先修改服务器 sshd 或清空配置目录。

这类问题最浪费时间的地方在于：错误信息看起来像配置或安全校验问题，但真正故障点在客户端软件版本。排查时只要先区分“系统 OpenSSH 路径”和“客户端内置 SSH 路径”，就能快速缩小范围。

Leave a Reply

Your email address will not be published. Required fields are marked *